Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue

[Jeff Garzik]

Linus Torvalds wrote:
(For example: I have three machines that I know have working MMCONF. On 
only one of theose does Linux actually even enable MMCONF accesses, 
because on the two other ones the BIOSes do the crazy "put it in some 
space that is reserved by PnP crap later", so we actually refuse to touch 
it. So at least in my limited environment, we hardly get any MMCONFIG test 
coverage, exactly because we have to be so totally anal about not enabling 
it early, because we cannot guarantee that it's not clashing with anything 
else).


Definitely.  So, two questions:


What's the preferred way to deal with the desire to view extended config 
space with "lspci -vvvxxx"?




Right now, we enable mmconfig for the bus/domain range requested by the 
BIOS [heh, so by implication many early BIOSen stomp themselves].


Is there a path for hw vendors, after passing 1,001 anal checks, to 
maintain the current behavior as it exists today in 
arch/x86/pci/mmconfig_{32,64}.c?


Jeff


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue

[Jeff Garzik]

Ivan Kokshaysky wrote:

On Sun, Dec 23, 2007 at 12:44:30AM -0500, Jeff Garzik wrote:
Failures are more predictable and more consistent with an all-or-none 
scenario.  The all-or-none solutions are the least complex on the software 
side, and far more widely tested than any mixed config access scheme.


Nope. The vast majority of mmconfig problems that happen at boot time
actually have nothing to do with "broken" or "working" mmconfig.
Typically these are
- mmconf area overlapped during BAR sizing;
- BIOS (or kernel) placed some MMIO in the middle of mmconfig area,
  which looks like some random device "doesn't like mmconfig".

This is a result of all-or-none approach, as mmconfig is fundamentally
unsafe until after PCI init is done.


The phrase "all or none" specifically describes the current practice in 
arch/x86/pci/mmconfig_{32,64}.c whereby a PCI bus always has one, and 
only one, access method.


So the problems you describe are unrelated to "all or none" as I was 
describing it.




The mixed access that Loic proposes allows to avoid these boot problems
just for free.


False.  If you have overlapping areas, then clearly it is 
board-dependent (undefined) what happens -- you might trigger an 
mmconfig access by writel() to your PCI device's MMIO BAR space.


Consider, too, what the current code in arch/x86/pci/mmconfig_{32,64}.c 
does:  it uses the range BIOS told to use for mmconfig, no more no less.


Clearly many early mmconfig BIOSes have buggy resource allocation... 
Thus if mmconfig is not known working on a system, turn it off 100% for 
all buses.  End of story.




Systems that have both non-mmconf PCI(X) and mmconf PCI-E
domains could be handled almost for free as well.


The existing code in arch/x86/pci/mmconfig_{32,64}.c today handles 
mixing of PCI-E and PCI-X just fine.  As noted above, its done on a 
per-bus and per-segment basis today.




And probably most important thing is that the x86 pci_conf implementation
would be so much simpler and cleaner that I honestly don't understand
why are we still discussing it ;-)


The proposed API adds code, so I don't see how it simplifies things.

The current approach is quite clean anyway:

1) "raw_pci_ops" points to a single set of PCI config accessors.
2) For mmconfig, if the BIOS did not tell us to use mmconfig with a 
given PCI bus, fall back to type1 accesses.




At the same time, making drivers to request extended config space
still makes sense. I think of pci_request_ext_conf(dev, drv_name) which
doesn't set any per-device flag, but
- returns success or failure depending on mmconf availability;
- can be logged by kernel to make it easier to debug if something
  goes wrong.


I agree with the function as noted in response to Linus's "Sound ok with 
this plan?" email.  But note -- users and developers also need to access 
extended config space, even if driver did not request it.  Even if there 
is no driver at all.


Otherwise the value of "lspci -vvvxxx" debugging reports from users is 
diminished.


Jeff


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC/PATCH 4/4] [POWERPC] pci: Disable IO/Mem on a device when resources can't be allocated

[Grant Grundler]

On Tue, Dec 18, 2007 at 10:01:15AM +1100, Benjamin Herrenschmidt wrote:
> This patch changes the PowerPC PCI code to disable IO and/or Memory
> decoding on a PCI device when a resource of that type failed to be
> allocated. This is done to avoid having unallocated dangling BARs enabled
> that might try to decode on top of other devices.
> 
> If a proper resource is assigned later on, then pci_enable_device{,_io,_mem}
> will take care of re-enabling decoding.
> 
> Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>

> @@ -1062,8 +1065,12 @@ static void __init pcibios_allocate_reso
>   disabled = !(command & PCI_COMMAND_IO);
>   else
>   disabled = !(command & PCI_COMMAND_MEMORY);
> - if (pass == disabled)
> - alloc_resource(dev, idx);
> + if (pass == disabled && alloc_resource(dev, idx)) {
> + command &= ~(r->flags & (IORESOURCE_IO |
> +  IORESOURCE_MEM));

While this may be ok for PPC, in general, wouldn't we want to only disable
which ever type of resource that couldn't be allocated?
ie make two calls: alloc_resource_io() and alloc_resource_mem() and disable
the respective flag if the alloc call fails?
Thus a device which was enable and programmed by BIOS could remain functional
despite one resource not being allocated.
(e.g. MMIO was allocated successfully while IO Port space was not)

Again, this is just a hypothetical question since I have no example (yet)
off hand where this is true. ISTR, the original discussion around
pci_enable_device_bars() suggested some machines already have this issue.

cheers,
grant

> + pci_write_config_word(dev,
> +   PCI_COMMAND, command);
> + }
>   }
>   if (pass)
>   continue;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC/PATCH 2/4] pci: Remove users of pci_enable_device_bars()

[Grant Grundler]

Just a style nit...

On Tue, Dec 18, 2007 at 10:01:14AM +1100, Benjamin Herrenschmidt wrote:
> This patch converts users of pci_enable_device_bars() to the new
> pci_enable_device_{io,mem} interface.
> 
> The new API fits nicely, except maybe for the QLA case where a bit of
> code re-organization might be a good idea but I prefer sticking to the
> simple patch as I don't have hardware to test on.
> 
> I'll also need some feedback on the cs5520 change.
> 
> Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>

>   /* We must not grab the entire device, it has 'ISA' space in its
> -BARS too and we will freak out other bits of the kernel */
> - if (pci_enable_device_bars(dev, 1<<2)) {
> +  * BARS too and we will freak out other bits of the kernel
> +  *
> +  * pci_enable_device_bars() is going away. I replaced it with
> +  * IO only enable for now but I'll need confirmation this is
> +  * allright for that device. If not, it will need some kind of
> +  * quirk. --BenH.
> +  */

This comment doesn't really belong in the code. It should be part of
the commit log or email RFC.

cheers,
grant
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC/PATCH 3/4] pci: Remove pci_enable_device_bars()

[Grant Grundler]

On Tue, Dec 18, 2007 at 10:01:14AM +1100, Benjamin Herrenschmidt wrote:
> Now that all in-tree users are gone, this removes pci_enable_device_bars()
> completely.

Almost completely.
Patch below removes pci_enable_device_bars() from Documentation/pci.txt .

(And I'd be happy to review patches to pci.txt that add
  pci_enable_device_io() and _mmio() as well. )

Signed-off-by: Grant Grundler <[EMAIL PROTECTED]>


diff --git a/Documentation/pci.txt b/Documentation/pci.txt
index 7754f5a..72b20c6 100644
--- a/Documentation/pci.txt
+++ b/Documentation/pci.txt
@@ -274,8 +274,6 @@ the PCI device by calling pci_enable_device(). This will:
o allocate an IRQ (if BIOS did not).
 
 NOTE: pci_enable_device() can fail! Check the return value.
-NOTE2: Also see pci_enable_device_bars() below. Drivers can
-attempt to enable only a subset of BARs they need.
 
 [ OS BUG: we don't check resource allocations before enabling those
   resources. The sequence would make more sense if we called
@@ -605,40 +603,7 @@ device lists. This is still possible but discouraged.
 
 
 
-10. pci_enable_device_bars() and Legacy I/O Port space
-~~
-
-Large servers may not be able to provide I/O port resources to all PCI
-devices. I/O Port space is only 64KB on Intel Architecture[1] and is
-likely also fragmented since the I/O base register of PCI-to-PCI
-bridge will usually be aligned to a 4KB boundary[2]. On such systems,
-pci_enable_device() and pci_request_region() will fail when
-attempting to enable I/O Port regions that don't have I/O Port
-resources assigned.
-
-Fortunately, many PCI devices which request I/O Port resources also
-provide access to the same registers via MMIO BARs. These devices can
-be handled without using I/O port space and the drivers typically
-offer a CONFIG_ option to only use MMIO regions
-(e.g. CONFIG_TULIP_MMIO). PCI devices typically provide I/O port
-interface for legacy OSes and will work when I/O port resources are not
-assigned. The "PCI Local Bus Specification Revision 3.0" discusses
-this on p.44, "IMPLEMENTATION NOTE".
-
-If your PCI device driver doesn't need I/O port resources assigned to
-I/O Port BARs, you should use pci_enable_device_bars() instead of
-pci_enable_device() in order not to enable I/O port regions for the
-corresponding devices. In addition, you should use
-pci_request_selected_regions() and pci_release_selected_regions()
-instead of pci_request_regions()/pci_release_regions() in order not to
-request/release I/O port regions for the corresponding devices.
-
-[1] Some systems support 64KB I/O port space per PCI segment.
-[2] Some PCI-to-PCI bridges support optional 1KB aligned I/O base.
-
-
-
-11. MMIO Space and "Write Posting"
+10. MMIO Space and "Write Posting"
 ~~
 
 Converting a driver from using I/O Port space to using MMIO space
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue

[Jeff Garzik]

Arjan van de Ven wrote:

3) mmconfig might or might not be enabled, depending on which driver
is loaded, whether it called an API or not.

Even LESS testing by hw vendors than #2.  Maybe even "never"

Inconsistent (config access depends on device)


the "depends on device" is even true for Linux today. For us today, MMCONFIG 
isn't always used, it's used on a per device basis already; except that the per-device is 
both defined by the bios and our quirks
(the mmconfig code already falls back to conf1 cycles in various cases)

So I'm not entirely buying your argument. IN fact I'm not buying your "mixed is not 
tested at all" argument; while the statement may be true, it's not different than it 
is from Linux today... which is mixed. Just differently mixed I suppose.


/If/ mixed use is truly well tested, then that eliminates one of my two 
objections.


But I don't see that in the code now...  I see we choose [get_virt() in 
mmconfig_{32,6 4}.c} strictly on a per-bus basis, based on the allowed 
bus list provided by the BIOS.


In other words, if the BIOS says "use this segment/bus range for 
mmconfig", the code does that.  There is no mixing of accesses on a 
per-device basis AFAICS in the current code.  (feel free to prove me 
wrong! :))  It looks like per-bus/domain to me, which is a more 
reasonable and expected arrangement than per-device mmconfig|typeN conf 
accesses.


At boot time, we use type1 accesses until a "flag day", at which time an 
entire bus is switched to mmconfig all at once.  After that point there 
is no mixing of accesses on that bus -- and nor were there mixed 
accesses on that bus /before/ that point.


And -- please forgive me, I mean no offense here -- we have to make sure 
whatever rule we come up with makes AMD and other non-Intel folks happy. 
 Like with PCI MSI, mmconfig (+ its Linux support) has a history of 
being written first for Intel, working great on select Intel platforms, 
and not working so great initially for other vendors even when said 
technology is supposedly compatible.  So having AMD sign-off on such an 
approach would greatly increase comfort level.




The second objection was regarding the inconsistencies introduced to 
userland (and the kernel?) whereby the existing states:


* 256b config space
* on per-bus basis, ext cfg space is available
  if device provides && mmconfig active

were joined by the additional state

* on a per-bus basis, ext cfg space is available
  if device provides && mmconfig active

which has the potential to confuse the codebase that makes assumptions 
based upon whole system (mmconfig or not) and per-bus (ext cfg space 
capable or not) basis.


So, if my two worries here are needless, then those objections are 
eliminated.





Finally, I wonder if anything can be done about the diagnostic angle: 
it is not __only__ the driver that may want extended config space access.


It is quite reasonable and logical for an admin or developer to want to 
_view_ the entire extended cfg space (with lspci -vvvxxx) of a device, 
even if the device has not called pci_enable_ext_cfg_space(); indeed, 
even if a driver is not loaded at all.


How to address that need?

Jeff



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] [Patch] calgary iommu: Use the first kernel's tce tables in kdump

[Chandru]

Hi Muli,

I have tried to work with CCR ,CSR, CSMR, CSAR, CFGRW, GBRERRM  
registers but have been unable to make calgary generate an exception 
upon error condition.  In alloc_tce_table() , I am setting WRITE_ONLY 
access permission bit to tce entries but it isn't helping.  Would you 
kindly let me know how we can make calgary to generate an exception in 
error conditions ?.


Thanks,
Chandru

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] UPDATED: hfs: handle more on-disk corruptions without oopsing

[Eric Sandeen]

Roman Zippel wrote:
> Hi,
> 
> On Thursday 20 December 2007, Eric Sandeen wrote:
> 
>> Index: linux-2.6.24-rc3/fs/hfs/brec.c
>> ===
>> --- linux-2.6.24-rc3.orig/fs/hfs/brec.c
>> +++ linux-2.6.24-rc3/fs/hfs/brec.c
>> @@ -44,10 +44,21 @@ u16 hfs_brec_keylen(struct hfs_bnode *no
>>  recoff = hfs_bnode_read_u16(node, node->tree->node_size - (rec 
>> + 1) *
>> 2); if (!recoff)
>>  return 0;
>> -if (node->tree->attributes & HFS_TREE_BIGKEYS)
>> +if (node->tree->attributes & HFS_TREE_BIGKEYS) {
>>  retval = hfs_bnode_read_u16(node, recoff) + 2;
>> -else
>> +if (retval > node->tree->max_key_len + 2) {
>> +printk(KERN_ERR "hfs: keylen %d too large\n",
>> +retval);
>> +retval = HFS_BAD_KEYLEN;
>> +}
>> +} else {
>>  retval = (hfs_bnode_read_u8(node, recoff) | 1) + 1;
>> +if (retval > node->tree->max_key_len + 1) {
>> +printk(KERN_ERR "hfs: keylen %d too large\n",
>> +retval);
>> +retval = HFS_BAD_KEYLEN;
>> +}
>> +}
>>  }
>>  return retval;
>>  }
> 
> You can reuse 0 as failure value, a key has to be of nonzero size.

Ok.  Based on the other 0 returns I wasn't sure if they were considered
real errors or not... but also ISTR I ran into problems with a simple 0
return; I probably just to be sure need the callers check for it.

>> Index: linux-2.6.24-rc3/fs/hfs/btree.c
>> ===
>> --- linux-2.6.24-rc3.orig/fs/hfs/btree.c
>> +++ linux-2.6.24-rc3/fs/hfs/btree.c
>> @@ -81,6 +81,17 @@ struct hfs_btree *hfs_btree_open(struct
>>  goto fail_page;
>>  if (!tree->node_count)
>>  goto fail_page;
>> +if ((id == HFS_EXT_CNID) && (tree->max_key_len != HFS_MAX_EXT_KEYLEN)) {
>> +printk(KERN_ERR "hfs: invalid extent max_key_len %d\n",
>> +tree->max_key_len);
>> +goto fail_page;
>> +}
>> +if ((id == HFS_CAT_CNID) && (tree->max_key_len != HFS_MAX_CAT_KEYLEN)) {
>> +printk(KERN_ERR "hfs: invalid catalog max_key_len %d\n",
>> +tree->max_key_len);
>> +goto fail_page;
>> +}
>> +
>>  tree->node_size_shift = ffs(size) - 1;
>>  tree->pages_per_bnode = (tree->node_size + PAGE_CACHE_SIZE - 1) >>
>> PAGE_CACHE_SHIFT;
>>
> 
> I'd prefer a switch statement here.

Ok, I'd thought about doing it that way... :)

> It would be nice if you could do the same changes for hfsplus, so both stay 
> in 
> sync.

Yep, wanted to first see if it'd fly for HFS...

Thanks for the feedback,
-Eric

> Thanks.
> 
> bye, Roman

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Build breakage on powerpc with 2.6.24-rc6-mm1

[Greg KH]

On Mon, Dec 24, 2007 at 01:43:53PM +1100, Stephen Rothwell wrote:
> Hi Balbir,
> 
> Thanks for the report.
> 
> On Mon, 24 Dec 2007 04:11:58 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote:
> >
> > I see the following error with the iseries_veth driver in 2.6.24-rc6-mm1
> > 
> > drivers/net/iseries_veth.c: In function ‘veth_init_connection’:
> > drivers/net/iseries_veth.c:818: warning: unused variable ‘rc’
> > drivers/net/iseries_veth.c: In function ‘veth_probe_one’:
> > drivers/net/iseries_veth.c:1086: error: ‘veth_port_ktypeq’ undeclared
> > (first use in this function)
> > drivers/net/iseries_veth.c:1086: error: (Each undeclared identifier is
> > reported only once
> > drivers/net/iseries_veth.c:1086: error: for each function it appears
> > in.)
> > make[2]: *** [drivers/net/iseries_veth.o] Error 1
> > make[1]: *** [drivers/net] Error 2
> > make: *** [drivers] Error 2

Thanks for the report, sorry for the typos, I'll fix up my patch.

> Yeah, that would be
> gregkh-driver-kobject-convert-drivers-net-iseries_vethc-to-use-kobject_init-add_ng.
> 
> Hi Greg, do you even build with your patches applied?

For the power architecture, no, I do not.  I used to, but my cross-build
box died and I haven't taken the time to set it all up again.  For i386
and x86-64 I do build everything, and as that's 99% of the users, it's
usually fine :)

I did start to try to get a s390 cross-build working, but ran out of
time a week or so ago...

> > Here's a patch, compile tested to fix the compilation problem
> 
> Hopefully Greg will fix his original patch before it reaches Linus.

I will do that.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: drivers/net/iseries_veth.c dubious sysfs usage

[Greg KH]

On Mon, Dec 24, 2007 at 01:52:08PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> On Wed, 12 Dec 2007 23:08:29 -0800 Greg KH <[EMAIL PROTECTED]> wrote:
> >
> > Hm, ok, it's odd as you are the only driver in the whole tree doing
> > something like this, but it seems semi-resonable, so I can't complain :)
> > 
> > I'll fix the core up to allow you to do this, thanks for the
> > explanation.
> 
> So if this "seems semi-reasonable", why was the result
> gregkh-driver-driver-add-driver_add_kobj-for-looney-iseries_veth-driver
> containing "Hopefully no one uses this function in the future and the
> iseries_veth driver authors come to their senses so I can remove this
> hack..." as part of its comment.  If you expect respect, you need to
> treat others the same way ...

Well, sarcasm doesn't come accross very easily in changelog comments it
seems :)

> If what the driver writers are doing is "looney" (in your opinion), then
> please describe a better way of doing what they are trying to do.
> Sometimes, if people have to abuse the infrastructure, it is possible that
> the infrastructure is lacking?

In thinking about this some more, no, I think you all are abusing the
infrastructure here.  This is the ONLY driver in the entire kernel tree
that thinks it is acceptable to hang kobjects off of the driver
structure.  For some reason, no one else does this either because they
never would think of doing such a thing, or that they are not as unique
as this driver.

So I take back the "semi-resonable" statement above.  Please prove to me
that:
- it is ok to hang kobjects off of a driver when:
- no userspace tool will ever be notified that they have
  been created
- no known userspace library knows how to find such
  attributes (libsysfs can't do that last I looked, and
  it's no longer maintained.)
- there is no documentation in the Documentation/ABI/
  explaining this usage.
- this can not be just a easily expressed in debugfs, or some
  other representation (netlink for configuration, configfs,
  some other location in sysfs, a driver-specific filesystem,
  etc.)
- that there is a tool out there using this current interface.

I don't like this usage of sysfs as it is very abnormal, and we are
trying very hard to fix up the rough edges here, to:
- make it easier to program to and not get things incorrect
  within the kernel
- present a unified, semi-sane interface that is documented well
  to userspace so users don't get even madder then they
  currently are.


thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Boot time module loading problem

[Larry Finger]

Shourya Sarcar wrote:
> Larry Finger wrote:
>> With 2.6.24-rc5, a b43 user reports a problem at bootup. The b43
>> module, which should be loaded by the ssb module, fails with the
>> following type of message:
>>
>> ssb: Sonics Silicon Backplane found on PCI device :0c:00.0 b43:
>> disagrees about version of symbol ssb_device_is_enabled b43: Unknown
>> symbol ssb_device_is_enabled b43: disagrees about version of symbol
>> ssb_pcicore_dev_irqvecs_enable b43: Unknown symbol
>> ssb_pcicore_dev_irqvecs_enable b43: disagrees about version of symbol
>> ssb_bus_may_powerdown b43: Unknown symbol ssb_bus_may_powerdown
>>
>> < and more similar lines>
>>
>> If the user issues the commands
>>
>> rmmod ssb; modprobe b43
>>
>> then the modules are loaded correctly and the wireless device works.
>>
>> What could be causing such a problem?
>>
>> Larry
>>
> 
> Larry, thanks for pursuing this. I upgraded to 2.6.24-rc6 last night and
> I don't see this issue anymore. One might think that the clean remake
> solved the problem (which I am pretty sure I did with rc5 as well); but
> still does not explain with 2.6.24-rc5, the module would not load on
> first attempt but then load after the manual:
> 
> # rmmod ssb;modprobe b43

Johannes may have been right and that you had a stale initrd. I was going to 
have you try a 'sudo
mkinitrd', but it is now fixed.

Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

SCSI errors on powerpc with 2.6.24-rc6-mm1

[Balbir Singh]

Hi,

I've just seen this on my dmesg, this is new, never seen this before on
this box and it happens only with this version of the kernel.

In this configuration, the page size is set to 64K and I've enabled fake
NUMA nodes on PowerPC.

tce_buildmulti_pSeriesLP: plpar_tce_put failed. rc=-4
index   = 0x402
npages  = 0x0
tce[0] val = 0x15ad0001
Call Trace:
[cffe74f0] [c00491a4]
.tce_buildmulti_pSeriesLP+0x26c/0x2ac (unreliable)
[cffe75c0] [c00295e4] .iommu_map_sg+0x1d4/0x418
[cffe76d0] [c0028664] .dma_iommu_map_sg+0x3c/0x50
[cffe7750] [c03b6c30] .scsi_dma_map+0x70/0x94
[cffe77d0] [c03dedbc] .ipr_queuecommand+0x300/0x500
[cffe7880] [c03ae964] .scsi_dispatch_cmd+0x21c/0x2b8
[cffe7920] [c03b67a0] .scsi_request_fn+0x310/0x460
[cffe79d0] [c024ab90] .blk_run_queue+0x94/0xec
[cffe7a70] [c03b3b08] .scsi_run_queue+0x24c/0x27c
[cffe7b20] [c03b4424] .scsi_next_command+0x48/0x70
[cffe7bc0] [c03b4b48] .scsi_end_request+0xbc/0xe4
[cffe7c60] [c03b5294] .scsi_io_completion+0x170/0x3e8
[cffe7d40] [c03ae0e4] .scsi_finish_command+0xb4/0xd4
[cffe7dd0] [c03b584c] .scsi_softirq_done+0x114/0x138
[cffe7e60] [c024af70] .blk_done_softirq+0xa0/0xd0
[cffe7ef0] [c007a2a0] .__do_softirq+0xa8/0x164
[cffe7f90] [c0027edc] .call_do_softirq+0x14/0x24
[c0003e183950] [c000bdcc] .do_softirq+0x74/0xc0
[c0003e1839e0] [c007a450] .irq_exit+0x5c/0xac
[c0003e183a60] [c000c414] .do_IRQ+0x17c/0x1f4
[c0003e183b00] [c0004c24] hardware_interrupt_entry+0x24/0x28
--- Exception: 501 at .ppc64_runlatch_off+0x28/0x60
LR = .pseries_dedicated_idle_sleep+0xd8/0x1a4
[c0003e183df0] [c0048494]
.pseries_dedicated_idle_sleep+0x78/0x1a4 (unreliable)
[c0003e183e80] [c001110c] .cpu_idle+0x10c/0x1e8
[c0003e183f00] [c002b5b0] .start_secondary+0x1b4/0x1d8
[c0003e183f90] [c00083c4] .start_secondary_prolog+0xc/0x10
ipr: 0:0:3:0: 8150: PCI bus error
ipr: IOASA Dump:
ipr: : 04418000 009000D0 0006FFD0 
ipr: 0010:    
ipr: 0020: 0106 D0001814 01062A00 000F531E
ipr: 0030: 0004  303800B6 
ipr: 0040:  0406 00CC AABB
ipr: 0050: 0006FFD0 6800FFD0 7FFF0030 B910
ipr: 0060: 4000 8800 0820 13FE
ipr: 0070:   8C0E 
ipr: 0080:    

-- 
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Major regression on hackbench with SLUB (more numbers)

[Alessandro Suardi]

On 22 Dec 2007 16:52:56 -0600, Jason L Tibbitts III <[EMAIL PROTECTED]> wrote:
> > "IM" == Ingo Molnar <[EMAIL PROTECTED]> writes:
>
> IM> Distros will likely pick SLUB if there's no performance worries
> IM> and if it's the default. Fedora rawhide already uses SLUB.
>
> Actually, it seems to me that not only does Fedora rawhide use SLUB,
> but Fedora 8 and 7 use it as well.  They don't have /proc/slabinfo and
> they all seem to have CONFIG_SLUB=y:
>
> > grep -r CONFIG_SLUB=y kernel
> kernel/devel/config-generic:CONFIG_SLUB=y
> kernel/F-7/configs/config-generic:CONFIG_SLUB=y
> kernel/F-8/config-generic:CONFIG_SLUB=y

Also true for at least recent versions of FC6 (which my bittorrent
 machine is still on), which currently run 2.6.22-14 based kernels.
And no, I didn't notice - that box usually hits triple-digit uptime
 before I reboot; in fact, it's still running a 2.6.22-9 based kernel.

--alessandro

 "Damaged people are dangerous. They know they can survive."

   (Anna Barton/Juliette Binoche, 'Damage')
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Major regression on hackbench with SLUB (more numbers)

[Theodore Tso]

On Sun, Dec 23, 2007 at 03:15:00PM +0100, Andi Kleen wrote:
> > Same here. In fact, I've always considered that procfs was for
> > humans while sysfs was for tools. sysfs reminds me too much the
> > unexploitable /devices in Solaris. With the proper tools, I think
> > we can do a lot with it, but it's not as intuitive to find the
> > proper tools as it was to do "ls" followed by "cat" in /proc.
> 
> find /sys/... -type f | while read i ; do echo "$i: $(<$i)" ; done
> 
> tends to work reasonably well for a quick overview, but yes
> cat was nicer for humans.

Until you start to wonder what the heck :a-136 is:

/sys/slab/:a-136/objs_per_slab: 30

Sigh...

- Ted

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] x86: kprobes remove fix_riprel #ifdef

[Harvey Harrison]

Move #ifdef around function definiton into the function and
unconditionally return on X86_32.  Saves an ifdef from the
one callsite.

Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
Ingo, Masami, final leftovers from some unsent kprobes unification work.

Net reduction of one #ifdef section.

 arch/x86/kernel/kprobes.c |   11 +++
 1 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/kprobes.c b/arch/x86/kernel/kprobes.c
index b1804e4..1ac532e 100644
--- a/arch/x86/kernel/kprobes.c
+++ b/arch/x86/kernel/kprobes.c
@@ -263,15 +263,16 @@ static int __kprobes is_IF_modifier(kprobe_opcode_t *insn)
return 0;
 }
 
-#ifdef CONFIG_X86_64
 /*
  * Adjust the displacement if the instruction uses the %rip-relative
  * addressing mode.
  * If it does, Return the address of the 32-bit displacement word.
  * If not, return null.
+ * Only applicable to X86_64
  */
 static void __kprobes fix_riprel(struct kprobe *p)
 {
+#ifdef CONFIG_X86_64
u8 *insn = p->ainsn.insn;
s64 disp;
int need_modrm;
@@ -335,15 +336,17 @@ static void __kprobes fix_riprel(struct kprobe *p)
*(s32 *)insn = (s32) disp;
}
}
-}
+#else
+   return;
 #endif
+}
 
 static void __kprobes arch_copy_kprobe(struct kprobe *p)
 {
memcpy(p->ainsn.insn, p->addr, MAX_INSN_SIZE * sizeof(kprobe_opcode_t));
-#ifdef CONFIG_X86_64
+
fix_riprel(p);
-#endif
+
if (can_boost(p->addr))
p->ainsn.boostable = 0;
else
-- 
1.5.4.rc0.1143.g1a8a



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] x86: Introduce REX prefix helper for kprobes

[Harvey Harrison]

Fold some small ifdefs into a helper function.

Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
Masami, Ingo, I had this left in some unsent kprobes unification
work.  Depends on your tastes, but does reduce ifdefs and is a bit
better about self-documenting the REX prefix on X86_64.

If I find places that could also use this I'll try to find a suitable
header any stick a static inline there instead.  Otherwise static to
kprobes.c is probably more appropriate for now.

 arch/x86/kernel/kprobes.c |   27 +++
 1 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/kprobes.c b/arch/x86/kernel/kprobes.c
index 4e33329..b1804e4 100644
--- a/arch/x86/kernel/kprobes.c
+++ b/arch/x86/kernel/kprobes.c
@@ -171,6 +171,19 @@ static void __kprobes set_jmp_op(void *from, void *to)
 }
 
 /*
+ * Check for the REX prefix which can only exist on X86_64
+ * X86_32 always returns 0
+ */
+static int __kprobes is_REX_prefix(kprobe_opcode_t *insn)
+{
+#ifdef CONFIG_X86_64
+   if ((*insn & 0xf0) == 0x40)
+   return 1;
+#endif
+   return 0;
+}
+
+/*
  * Returns non-zero if opcode is boostable.
  * RIP relative instructions are adjusted at copying time in 64 bits mode
  */
@@ -239,14 +252,14 @@ static int __kprobes is_IF_modifier(kprobe_opcode_t *insn)
case 0x9d:  /* popf/popfd */
return 1;
}
-#ifdef CONFIG_X86_64
+
/*
-* on 64 bit x86, 0x40-0x4f are prefixes so we need to look
+* on X86_64, 0x40-0x4f are REX prefixes so we need to look
 * at the next byte instead.. but of course not recurse infinitely
 */
-   if (*insn  >= 0x40 && *insn <= 0x4f)
+   if (is_REX_prefix(insn))
return is_IF_modifier(++insn);
-#endif
+
return 0;
 }
 
@@ -284,7 +297,7 @@ static void __kprobes fix_riprel(struct kprobe *p)
}
 
/* Skip REX instruction prefix.  */
-   if ((*insn & 0xf0) == 0x40)
+   if (is_REX_prefix(insn))
++insn;
 
if (*insn == 0x0f) {
@@ -748,11 +761,9 @@ static void __kprobes resume_execution(struct kprobe *p,
unsigned long orig_ip = (unsigned long)p->addr;
kprobe_opcode_t *insn = p->ainsn.insn;
 
-#ifdef CONFIG_X86_64
/*skip the REX prefix*/
-   if (*insn >= 0x40 && *insn <= 0x4f)
+   if (is_REX_prefix(insn))
insn++;
-#endif
 
regs->flags &= ~X86_EFLAGS_TF;
switch (*insn) {
-- 
1.5.4.rc0.1143.g1a8a


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: do not stop/start devices in suspend/resume path: the SCSI case

[Bjorn Helgaas]

On Sunday 23 December 2007 6:43:49 pm Stephane Ascoet wrote:
> Bjorn Helgaas a écrit :
> > Good.  It's not clear to me whether it is safe to leave devices
> > enabled while we sleep.  I don't see an actual problem, but there
> > might be something related to hotplug while we're asleep or something.
> > So I'll cc: some additional people who might have some insight.
>
> Hi, is there a chance for SCSI sleeping being managed by ACPI(it seems
> to be the case for IDE)?

I'm sorry, I don't know the answer to this.

Bjorn

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM

[Carlos Corbacho]

On Monday 24 December 2007 01:14:34 Linus Torvalds wrote:
> Side note: we could obviously undo the commit that triggered this for you
> [..]
> In other words, we'd have to go back to our original ordering, which Len
> said was fundamentally wrong. I don't think anybody really wants that.

Nor would I argue to do so.

> It would be better to figure out why "device_suspend()" apparently causes
> problems for your AML crud.

Will do - thanks for the pointer.

> Oh, and why is linux-kernel cc'd, but not linux-pm?

Because I like to compound my errors (I mean, if you're going to screw up, you 
might as well _really_ go for it).

-Carlos
-- 
E-Mail: [EMAIL PROTECTED]
Web: strangeworlds.co.uk
GPG Key ID: 0x23EE722D
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: drivers/net/iseries_veth.c dubious sysfs usage

[Stephen Rothwell]

Hi Greg,

On Wed, 12 Dec 2007 23:08:29 -0800 Greg KH <[EMAIL PROTECTED]> wrote:
>
> Hm, ok, it's odd as you are the only driver in the whole tree doing
> something like this, but it seems semi-resonable, so I can't complain :)
> 
> I'll fix the core up to allow you to do this, thanks for the
> explanation.

So if this "seems semi-reasonable", why was the result
gregkh-driver-driver-add-driver_add_kobj-for-looney-iseries_veth-driver
containing "Hopefully no one uses this function in the future and the
iseries_veth driver authors come to their senses so I can remove this
hack..." as part of its comment.  If you expect respect, you need to
treat others the same way ...

If what the driver writers are doing is "looney" (in your opinion), then
please describe a better way of doing what they are trying to do.
Sometimes, if people have to abuse the infrastructure, it is possible that
the infrastructure is lacking?

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]


pgpamHJhoyaOo.pgp
Description: PGP signature

Re: [PATCH] Avoid overflows in kernel/time.c (version 5)

[Roman Zippel]

Hi,

On Monday 17 December 2007, H. Peter Anvin wrote:

>  kernel/timeconst.pl   |  340

I agree with Jan that it would be better to put this into scripts.
In the long term we could also detect some of the simple special cases, so we 
can finally inline some of these functions again, this would mean the 
generated file would go into include/linux/ and the script should be in 
scripts/.

> + my ($b,$n,$d) = @_;

I noticed this already in the old script, using something else than single 
letter variables would increase readability considerably.

bye, Roman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] UPDATED: hfs: handle more on-disk corruptions without oopsing

[Roman Zippel]

Hi,

On Thursday 20 December 2007, Eric Sandeen wrote:

> Index: linux-2.6.24-rc3/fs/hfs/brec.c
> ===
> --- linux-2.6.24-rc3.orig/fs/hfs/brec.c
> +++ linux-2.6.24-rc3/fs/hfs/brec.c
> @@ -44,10 +44,21 @@ u16 hfs_brec_keylen(struct hfs_bnode *no
>   recoff = hfs_bnode_read_u16(node, node->tree->node_size - (rec 
> + 1) *
> 2); if (!recoff)
>   return 0;
> - if (node->tree->attributes & HFS_TREE_BIGKEYS)
> + if (node->tree->attributes & HFS_TREE_BIGKEYS) {
>   retval = hfs_bnode_read_u16(node, recoff) + 2;
> - else
> + if (retval > node->tree->max_key_len + 2) {
> + printk(KERN_ERR "hfs: keylen %d too large\n",
> + retval);
> + retval = HFS_BAD_KEYLEN;
> + }
> + } else {
>   retval = (hfs_bnode_read_u8(node, recoff) | 1) + 1;
> + if (retval > node->tree->max_key_len + 1) {
> + printk(KERN_ERR "hfs: keylen %d too large\n",
> + retval);
> + retval = HFS_BAD_KEYLEN;
> + }
> + }
>   }
>   return retval;
>  }

You can reuse 0 as failure value, a key has to be of nonzero size.

> Index: linux-2.6.24-rc3/fs/hfs/btree.c
> ===
> --- linux-2.6.24-rc3.orig/fs/hfs/btree.c
> +++ linux-2.6.24-rc3/fs/hfs/btree.c
> @@ -81,6 +81,17 @@ struct hfs_btree *hfs_btree_open(struct
>   goto fail_page;
>   if (!tree->node_count)
>   goto fail_page;
> + if ((id == HFS_EXT_CNID) && (tree->max_key_len != HFS_MAX_EXT_KEYLEN)) {
> + printk(KERN_ERR "hfs: invalid extent max_key_len %d\n",
> + tree->max_key_len);
> + goto fail_page;
> + }
> + if ((id == HFS_CAT_CNID) && (tree->max_key_len != HFS_MAX_CAT_KEYLEN)) {
> + printk(KERN_ERR "hfs: invalid catalog max_key_len %d\n",
> + tree->max_key_len);
> + goto fail_page;
> + }
> +
>   tree->node_size_shift = ffs(size) - 1;
>   tree->pages_per_bnode = (tree->node_size + PAGE_CACHE_SIZE - 1) >>
> PAGE_CACHE_SHIFT;
>

I'd prefer a switch statement here.

It would be nice if you could do the same changes for hfsplus, so both stay in 
sync.
Thanks.

bye, Roman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Build breakage on powerpc with 2.6.24-rc6-mm1

[Stephen Rothwell]

Hi Balbir,

Thanks for the report.

On Mon, 24 Dec 2007 04:11:58 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote:
>
> I see the following error with the iseries_veth driver in 2.6.24-rc6-mm1
> 
> drivers/net/iseries_veth.c: In function ‘veth_init_connection’:
> drivers/net/iseries_veth.c:818: warning: unused variable ‘rc’
> drivers/net/iseries_veth.c: In function ‘veth_probe_one’:
> drivers/net/iseries_veth.c:1086: error: ‘veth_port_ktypeq’ undeclared
> (first use in this function)
> drivers/net/iseries_veth.c:1086: error: (Each undeclared identifier is
> reported only once
> drivers/net/iseries_veth.c:1086: error: for each function it appears
> in.)
> make[2]: *** [drivers/net/iseries_veth.o] Error 1
> make[1]: *** [drivers/net] Error 2
> make: *** [drivers] Error 2

Yeah, that would be
gregkh-driver-kobject-convert-drivers-net-iseries_vethc-to-use-kobject_init-add_ng.

Hi Greg, do you even build with your patches applied?

> Here's a patch, compile tested to fix the compilation problem

Hopefully Greg will fix his original patch before it reaches Linus.

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


pgpe2wdfiwYdj.pgp
Description: PGP signature

Re: Boot time module loading problem

[Shourya Sarcar]

Larry Finger wrote:

With 2.6.24-rc5, a b43 user reports a problem at bootup. The b43
module, which should be loaded by the ssb module, fails with the
following type of message:

ssb: Sonics Silicon Backplane found on PCI device :0c:00.0 b43:
disagrees about version of symbol ssb_device_is_enabled b43: Unknown
symbol ssb_device_is_enabled b43: disagrees about version of symbol
ssb_pcicore_dev_irqvecs_enable b43: Unknown symbol
ssb_pcicore_dev_irqvecs_enable b43: disagrees about version of symbol
ssb_bus_may_powerdown b43: Unknown symbol ssb_bus_may_powerdown

< and more similar lines>

If the user issues the commands

rmmod ssb; modprobe b43

then the modules are loaded correctly and the wireless device works.

What could be causing such a problem?

Larry



Larry, thanks for pursuing this. I upgraded to 2.6.24-rc6 last night and
I don't see this issue anymore. One might think that the clean remake
solved the problem (which I am pretty sure I did with rc5 as well); but 
still does not explain with 2.6.24-rc5, the module would not load on 
first attempt but then load after the manual:


# rmmod ssb;modprobe b43

Best regards,
Shourya




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG 2.6.24-rc6-mm1] BUG() at check_irqs_on() in fs/buffer.c .

[Tetsuo Handa]

Hello.

Ingo Molnar wrote:
> does the patch below help?

Yes, it solved this bug.

Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.24-rc6-mm1

[Herbert Xu]

On Sun, Dec 23, 2007 at 12:14:10PM -0800, Andrew Morton wrote:
>
> No, the problem is that include/crypto/scatterwalk.h doesn't include enough
> header files to support its inlining fetish.  It needs sched.h.

I'll get it fixed in cryptodev.

> Ingo, it's not good that we have cond_resched() definitions conditionally
> duplicated in kernel.h - that's increasing the risk of bugs like this one.

Actually, why do we even have cond_resched when real preemption
is on? It seems to be a waste of space and time.

Any objections to something like this to remove cond_resched with
CONFIG_PREEMPT on (apart from the potential to uncover more bugs
like this one)?

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 94bc996..a7283c9 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -105,8 +105,8 @@ struct user;
  * supposed to.
  */
 #ifdef CONFIG_PREEMPT_VOLUNTARY
-extern int cond_resched(void);
-# define might_resched() cond_resched()
+extern int _cond_resched(void);
+# define might_resched() _cond_resched()
 #else
 # define might_resched() do { } while (0)
 #endif
diff --git a/include/linux/sched.h b/include/linux/sched.h
index ac3d496..ae8e9bd 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1863,7 +1863,18 @@ static inline int need_resched(void)
  * cond_resched_lock() will drop the spinlock before scheduling,
  * cond_resched_softirq() will enable bhs before scheduling.
  */
-extern int cond_resched(void);
+#ifdef CONFIG_PREEMPT
+static inline int cond_resched(void)
+{
+   return 0;
+}
+#else
+extern int _cond_resched(void);
+static inline int cond_resched(void)
+{
+   return _cond_resched();
+}
+#endif
 extern int cond_resched_lock(spinlock_t * lock);
 extern int cond_resched_softirq(void);
 
diff --git a/kernel/sched.c b/kernel/sched.c
index 3df84ea..2dc2bbf 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -4683,7 +4683,8 @@ static void __cond_resched(void)
} while (need_resched());
 }
 
-int __sched cond_resched(void)
+#if !defined(CONFIG_PREEMPT) || defined(CONFIG_PREEMPT_VOLUNTARY)
+int __sched _cond_resched(void)
 {
if (need_resched() && !(preempt_count() & PREEMPT_ACTIVE) &&
system_state == SYSTEM_RUNNING) {
@@ -4692,7 +4693,8 @@ int __sched cond_resched(void)
}
return 0;
 }
-EXPORT_SYMBOL(cond_resched);
+EXPORT_SYMBOL(_cond_resched);
+#endif
 
 /*
  * cond_resched_lock() - if a reschedule is pending, drop the given lock,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM

[Linus Torvalds]

On Sun, 23 Dec 2007, Linus Torvalds wrote:
> 
> IOW, it looks like the normal kind of ACPI mess. Color me not in the least 
> surprised, and it needs somebody who understands AML and what the heck is 
> supposed to happen to figure out.

Side note: we could obviously undo the commit that triggered this for you 
(ie 52ade9b3b97fd3bea42842a056fe0786c28d0555), but then we have to undo 
also the commit that caused us to do that commit in the first place, and 
change the ordering on resume too (that would be commit 
e3c7db621bed4afb8e231cb005057f2feb5db557 - the commit that moved the 
"pm_ops->finish()" call to before the call to device_resume())

In other words, we'd have to go back to our original ordering, which Len 
said was fundamentally wrong. I don't think anybody really wants that.

It would be better to figure out why "device_suspend()" apparently causes 
problems for your AML crud.

Oh, and why is linux-kernel cc'd, but not linux-pm? Are all the relevant 
people from linux-pm cc'd, or should somebody who is on that list please 
try to condense this down?

(For linux-pm: see 

http://bugzilla.kernel.org/show_bug.cgi?id=9528

for some more details, including a few red herrings like the whole subject 
line of this email thread which turned out to not be valid after all).

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 00/20] VM pageout scalability improvements

[Rik van Riel]

On Mon, 24 Dec 2007 04:29:36 +0530
Balbir Singh <[EMAIL PROTECTED]> wrote:
> Rik van Riel wrote:

> > In the real world, users with large JVMs on their servers, which
> > sometimes go a little into swap, can trigger this system.  All of
> > the CPUs end up scanning the active list, and all pages have the
> > referenced bit set.  Even if the system eventually recovers, it
> > might as well have been dead.
> > 
> > Going into swap a little should only take a little bit of time.
> 
> Very fascinating, so we need to scale better with larger memory.
> I suspect part of the answer will lie with using large/huge pages.

Linus vetoed going to a larger soft page size, with good reason.

Just look at how much the 64kB page size on PPC64 sucks for most
workloads - it works for PPC64 because people buy PPC64 monster
systems for the kinds of monster workloads that work well with a
large page size, but it definately isn't general purpose.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 17/20] non-reclaimable mlocked pages

[Rik van Riel]

On Sun, 23 Dec 2007 23:22:08 +1100
Nick Piggin <[EMAIL PROTECTED]> wrote:

> Not sure how well that translates to real world workloads, but it
> might help somewhere. Admittedly some of the patches are pretty
> complex...

I like your patch series.

They are completely orthogonal to my patches though, so I
won't tie them together by merging your series into mine :)

It looks like the majority of your patches could go into
-mm right away.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM

[Linus Torvalds]

On Mon, 24 Dec 2007, Carlos Corbacho wrote:
> 
> Please disregard the patch anyway - my test system was still using the custom 
> DSDT - it doesn't fix anything.

Ok, so it's not a simple IO port conflict.

And the range 0x1400-0x147f (which is apparently the ACPI block) is 
properly marked as reserved.

So the IO write to 1428 is a red herring. It's just part of the normal 
sequence to suspend-to-ram, and while it failing probably has something to 
do with the failure to s2ram, it's simply a result of ACPI doing something 
insane, and probably making some assumptions that we've broken by mistake 
when we do the higher-level device_suspend() before we do the low-level 
one.

IOW, it looks like the normal kind of ACPI mess. Color me not in the least 
surprised, and it needs somebody who understands AML and what the heck is 
supposed to happen to figure out.

The kernel doesn't do anything at all to port 1428 (since it is reserved), 
so if any write to it "fails" (how?) it's probably because the writer made 
some assumptions about system state.

Linus


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] PM: Do not destroy/create devices while suspended in msr.c

[Rafael J. Wysocki]

From: Rafael J. Wysocki <[EMAIL PROTECTED]>

The MSR driver should not attempt to destroy/create a suspended
device.

Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
 arch/x86/kernel/msr.c |3 ---
 1 file changed, 3 deletions(-)

Index: linux-2.6/arch/x86/kernel/msr.c
===
--- linux-2.6.orig/arch/x86/kernel/msr.c
+++ linux-2.6/arch/x86/kernel/msr.c
@@ -155,13 +155,10 @@ static int __cpuinit msr_class_cpu_callb
 
switch (action) {
case CPU_UP_PREPARE:
-   case CPU_UP_PREPARE_FROZEN:
err = msr_device_create(cpu);
break;
case CPU_UP_CANCELED:
-   case CPU_UP_CANCELED_FROZEN:
case CPU_DEAD:
-   case CPU_DEAD_FROZEN:
msr_device_destroy(cpu);
break;
}

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] PM: Do not destroy/create devices while suspended in mce_64.c

[Rafael J. Wysocki]

From: Rafael J. Wysocki <[EMAIL PROTECTED]>

The x86-64 MCE driver should not attempt to destroy/create a suspended
device.

Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
 arch/x86/kernel/cpu/mcheck/mce_64.c |2 --
 1 file changed, 2 deletions(-)

Index: linux-2.6/arch/x86/kernel/cpu/mcheck/mce_64.c
===
--- linux-2.6.orig/arch/x86/kernel/cpu/mcheck/mce_64.c
+++ linux-2.6/arch/x86/kernel/cpu/mcheck/mce_64.c
@@ -862,11 +862,9 @@ mce_cpu_callback(struct notifier_block *
 
switch (action) {
case CPU_ONLINE:
-   case CPU_ONLINE_FROZEN:
mce_create_device(cpu);
break;
case CPU_DEAD:
-   case CPU_DEAD_FROZEN:
mce_remove_device(cpu);
break;
}

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/3] PM: Do not destroy/create devices while suspended

[Rafael J. Wysocki]

Hi,

Some device drivers register CPU hotplug notifiers and use them to destroy
device objects when removing the corresponding CPUs and to create these objects
when adding the CPUs back.

Unfortunately, this is not the right thing to do during suspend/hibernation,
since in that cases the CPU hotplug notifiers are called after suspending
devices and before resuming them, so the operations in question are carried
out on the objects representing suspended devices which shouldn't be
unregistered behing the PM core's back.  Although right now it usually doesn't
lead to any practical complications, it will predictably deadlock if
gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch is applied.

The solution is to prevent drivers from removing/adding devices from within
CPU hotplug notifiers during suspend/hibernation using the FROZEN bit
in the notifier's action argument.  The following three patches modify the
MSR, x86-64 MCE and cpuid drivers along these lines.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] PM: Do not destroy/create devices while suspended in cpuid.c

[Rafael J. Wysocki]

From: Rafael J. Wysocki <[EMAIL PROTECTED]>

The cpuid driver should not attempt to destroy/create a suspended
device.

Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
 arch/x86/kernel/cpuid.c |3 ---
 1 file changed, 3 deletions(-)

Index: linux-2.6/arch/x86/kernel/cpuid.c
===
--- linux-2.6.orig/arch/x86/kernel/cpuid.c
+++ linux-2.6/arch/x86/kernel/cpuid.c
@@ -157,13 +157,10 @@ static int __cpuinit cpuid_class_cpu_cal
 
switch (action) {
case CPU_UP_PREPARE:
-   case CPU_UP_PREPARE_FROZEN:
err = cpuid_device_create(cpu);
break;
case CPU_UP_CANCELED:
-   case CPU_UP_CANCELED_FROZEN:
case CPU_DEAD:
-   case CPU_DEAD_FROZEN:
cpuid_device_destroy(cpu);
break;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 6/6] udf: fix sparse warnings (shadowing & mismatch between declaration and definition)

[marcin . slusarz]

fix sparse warnings:
fs/udf/super.c:1431:24: warning: symbol 'bh' shadows an earlier one
fs/udf/super.c:1347:21: originally declared here
fs/udf/super.c:472:6: warning: symbol 'udf_write_super' was not declared. 
Should it be static?

Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
CC: Christoph Hellwig <[EMAIL PROTECTED]>
---
 fs/udf/super.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/fs/udf/super.c b/fs/udf/super.c
index dc09c2d..c190317 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -469,7 +469,7 @@ static int udf_parse_options(char *options, struct 
udf_options *uopt)
return 1;
 }
 
-void udf_write_super(struct super_block *sb)
+static void udf_write_super(struct super_block *sb)
 {
lock_kernel();
 
@@ -1428,7 +1428,6 @@ static int udf_load_partition(struct super_block *sb, 
kernel_lb_addr *fileset)
map->s_type_specific.s_virtual.s_num_entries =
(sbi->s_vat_inode->i_size - 36) >> 2;
} else if (map->s_partition_type == UDF_VIRTUAL_MAP20) {
-   struct buffer_head *bh = NULL;
uint32_t pos;
 
pos = udf_block_map(sbi->s_vat_inode, 0);
-- 
1.5.3.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/6] udf: check if udf_load_logicalvol failed

[marcin . slusarz]

udf_load_logicalvol may fail eg in out of memory conditions - check it
and propagate error further

Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
CC: Christoph Hellwig <[EMAIL PROTECTED]>
---
 fs/udf/super.c |7 ++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/fs/udf/super.c b/fs/udf/super.c
index 0ea34c5..f138309 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -1183,6 +1183,7 @@ static int udf_process_sequence(struct super_block *sb, 
long block,
uint32_t vdsn;
uint16_t ident;
long next_s = 0, next_e = 0;
+   int ret;
 
memset(vds, 0, sizeof(struct udf_vds_record) * VDS_POS_LENGTH);
 
@@ -1258,7 +1259,11 @@ static int udf_process_sequence(struct super_block *sb, 
long block,
if (i == VDS_POS_PRIMARY_VOL_DESC) {
udf_load_pvoldesc(sb, bh);
} else if (i == VDS_POS_LOGICAL_VOL_DESC) {
-   udf_load_logicalvol(sb, bh, fileset); /* TODO: 
check return value */
+   ret = udf_load_logicalvol(sb, bh, fileset);
+   if (ret != 0) {
+   brelse(bh);
+   return ret;
+   }
} else if (i == VDS_POS_PARTITION_DESC) {
struct buffer_head *bh2 = NULL;
if (udf_load_partdesc(sb, bh)) {
-- 
1.5.3.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/6] udf: convert some macros to functions

[marcin . slusarz]

convert UDF_SB_ALLOC_BITMAP macro to udf_sb_alloc_bitmap function
convert UDF_SB_FREE_BITMAP macro to udf_sb_free_bitmap function

Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
CC: Christoph Hellwig <[EMAIL PROTECTED]>
---
 fs/udf/super.c  |   49 +++--
 fs/udf/udf_sb.h |   38 --
 2 files changed, 43 insertions(+), 44 deletions(-)

diff --git a/fs/udf/super.c b/fs/udf/super.c
index f138309..dc09c2d 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -932,6 +932,27 @@ static void udf_load_fileset(struct super_block *sb, 
struct buffer_head *bh,
  root->logicalBlockNum, root->partitionReferenceNum);
 }
 
+static struct udf_bitmap *udf_sb_alloc_bitmap(struct super_block *sb, __u32 
index)
+{
+   struct udf_part_map *map = &UDF_SB(sb)->s_partmaps[index];
+   int nr_groups = (map->s_partition_len + (sizeof(struct spaceBitmapDesc) 
<< 3) +
+   (sb->s_blocksize * 8) - 1) / (sb->s_blocksize * 8);
+   int size = sizeof(struct udf_bitmap) + (sizeof(struct buffer_head *) * 
nr_groups);
+   struct udf_bitmap *bitmap;
+
+   if (size <= PAGE_SIZE)
+   bitmap = kmalloc(size, GFP_KERNEL);
+   else
+   bitmap = vmalloc(size);
+   if (bitmap != NULL) {
+   memset(bitmap, 0x00, size);
+   bitmap->s_block_bitmap = (struct buffer_head **)(bitmap + 1);
+   bitmap->s_nr_groups = nr_groups;
+   } else
+   udf_error(sb, __FUNCTION__, "Unable to allocate space for 
bitmap and %d buffer_head pointers", nr_groups);
+   return bitmap;
+}
+
 static int udf_load_partdesc(struct super_block *sb, struct buffer_head *bh)
 {
struct partitionDesc *p;
@@ -982,7 +1003,7 @@ static int udf_load_partdesc(struct super_block *sb, 
struct buffer_head *bh)
  i, 
map->s_uspace.s_table->i_ino);
}
if (phd->unallocSpaceBitmap.extLength) {
-   UDF_SB_ALLOC_BITMAP(sb, i, s_uspace);
+   map->s_uspace.s_bitmap = 
udf_sb_alloc_bitmap(sb, i);
if (map->s_uspace.s_bitmap != NULL) {

map->s_uspace.s_bitmap->s_extLength =

le32_to_cpu(phd->unallocSpaceBitmap.extLength);
@@ -1012,7 +1033,7 @@ static int udf_load_partdesc(struct super_block *sb, 
struct buffer_head *bh)
  i, 
map->s_fspace.s_table->i_ino);
}
if (phd->freedSpaceBitmap.extLength) {
-   UDF_SB_ALLOC_BITMAP(sb, i, s_fspace);
+   map->s_fspace.s_bitmap = 
udf_sb_alloc_bitmap(sb, i);
if (map->s_fspace.s_bitmap != NULL) {

map->s_fspace.s_bitmap->s_extLength =

le32_to_cpu(phd->freedSpaceBitmap.extLength);
@@ -1501,6 +1522,22 @@ static void udf_close_lvid(struct super_block *sb)
}
 }
 
+static void udf_sb_free_bitmap(struct udf_bitmap *bitmap)
+{
+   int i;
+   int nr_groups = bitmap->s_nr_groups;
+   int size = sizeof(struct udf_bitmap) + (sizeof(struct buffer_head *) * 
nr_groups);
+
+   for (i = 0; i < nr_groups; i++)
+   if (bitmap->s_block_bitmap[i])
+   brelse(bitmap->s_block_bitmap[i]);
+
+   if (size <= PAGE_SIZE)
+   kfree(bitmap);
+   else
+   vfree(bitmap);
+}
+
 /*
  * udf_read_super
  *
@@ -1686,9 +1723,9 @@ error_out:
if (map->s_partition_flags & UDF_PART_FLAG_FREED_TABLE)
iput(map->s_fspace.s_table);
if (map->s_partition_flags & UDF_PART_FLAG_UNALLOC_BITMAP)
-   UDF_SB_FREE_BITMAP(sb, sbi->s_partition, s_uspace);
+   udf_sb_free_bitmap(map->s_uspace.s_bitmap);
if (map->s_partition_flags & UDF_PART_FLAG_FREED_BITMAP)
-   UDF_SB_FREE_BITMAP(sb, sbi->s_partition, s_fspace);
+   udf_sb_free_bitmap(map->s_fspace.s_bitmap);
if (map->s_partition_type == UDF_SPARABLE_MAP15)
for (i = 0; i < 4; i++)

brelse(map->s_type_specific.s_sparing.s_spar_map[i]);
@@ -1764,9 +1801,9 @@ static void udf_put_super(struct super_block *sb)
if (map->s_partition_flags & UDF_PART_FLAG_FREED_TABLE)
iput(map->s_fspace.s_table);
if (map->s_partition_flags & UDF_PART_FLAG_UNALLOC_BITMAP)
-   UDF_SB_FREE_BITMAP

[PATCH 3/6] udf: convert UDF_SB_ALLOC_PARTMAPS macro to udf_sb_alloc_partition_maps function

[marcin . slusarz]

- convert UDF_SB_ALLOC_PARTMAPS macro to udf_sb_alloc_partition_maps function
- convert kmalloc + memset to kzalloc
- check if kzalloc failed (partially)

Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
CC: Christoph Hellwig <[EMAIL PROTECTED]>
---
 fs/udf/super.c  |   20 ++--
 fs/udf/udf_sb.h |   13 -
 2 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/fs/udf/super.c b/fs/udf/super.c
index 246868c..0ea34c5 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -53,6 +53,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include "udf_sb.h"
@@ -226,6 +227,19 @@ static void __exit exit_udf_fs(void)
 module_init(init_udf_fs)
 module_exit(exit_udf_fs)
 
+static int __must_check udf_sb_alloc_partition_maps(struct super_block *sb, 
__u32 count)
+{
+   struct udf_sb_info *sbi = UDF_SB(sb);
+   sbi->s_partmaps = kzalloc(sizeof(struct udf_part_map) * count, 
GFP_KERNEL);
+   if (sbi->s_partmaps != NULL)
+   sbi->s_partitions = count;
+   else {
+   sbi->s_partitions = 0;
+   udf_error(sb, __FUNCTION__, "Unable to allocate space for %d 
partition maps", count);
+   }
+   return sbi->s_partmaps != NULL ? 0 : -ENOMEM;
+}
+
 /*
  * udf_parse_options
  *
@@ -1037,7 +1051,9 @@ static int udf_load_logicalvol(struct super_block *sb, 
struct buffer_head *bh,
 
lvd = (struct logicalVolDesc *)bh->b_data;
 
-   UDF_SB_ALLOC_PARTMAPS(sb, le32_to_cpu(lvd->numPartitionMaps));
+   i = udf_sb_alloc_partition_maps(sb, le32_to_cpu(lvd->numPartitionMaps));
+   if (i != 0)
+   return i;
 
for (i = 0, offset = 0;
 i < sbi->s_partitions && offset < le32_to_cpu(lvd->mapTableLength);
@@ -1242,7 +1258,7 @@ static int udf_process_sequence(struct super_block *sb, 
long block,
if (i == VDS_POS_PRIMARY_VOL_DESC) {
udf_load_pvoldesc(sb, bh);
} else if (i == VDS_POS_LOGICAL_VOL_DESC) {
-   udf_load_logicalvol(sb, bh, fileset);
+   udf_load_logicalvol(sb, bh, fileset); /* TODO: 
check return value */
} else if (i == VDS_POS_PARTITION_DESC) {
struct buffer_head *bh2 = NULL;
if (udf_load_partdesc(sb, bh)) {
diff --git a/fs/udf/udf_sb.h b/fs/udf/udf_sb.h
index 92e6d75..4d3bd77 100644
--- a/fs/udf/udf_sb.h
+++ b/fs/udf/udf_sb.h
@@ -43,19 +43,6 @@ static inline struct udf_sb_info *UDF_SB(struct super_block 
*sb)
 
 struct logicalVolIntegrityDescImpUse *udf_sb_lvidiu(struct udf_sb_info *sbi);
 
-#define UDF_SB_ALLOC_PARTMAPS(X,Y)\
-{\
-   struct udf_sb_info *sbi = UDF_SB(X);\
-   sbi->s_partmaps = kmalloc(sizeof(struct udf_part_map) * Y, GFP_KERNEL);\
-   if (sbi->s_partmaps != NULL) {\
-   sbi->s_partitions = Y;\
-   memset(sbi->s_partmaps, 0x00, sizeof(struct udf_part_map) * Y);\
-   } else {\
-   sbi->s_partitions = 0;\
-   udf_error(X, __FUNCTION__, "Unable to allocate space for %d 
partition maps", Y);\
-   }\
-}
-
 #define UDF_SB_ALLOC_BITMAP(X,Y,Z)\
 {\
struct udf_sb_info *sbi = UDF_SB(X);\
-- 
1.5.3.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/6] udf: fix coding style of super.c

[marcin . slusarz]

fix coding style errors found by checkpatch:
- assignments in if conditions
- braces {} around single statement blocks
- no spaces after commas
- printks without KERN_*
- lines longer than 80 characters
before: total: 50 errors, 207 warnings, 1835 lines checked
after:  total: 0 errors, 164 warnings, 1872 lines checked

all 164 warnings left are lines longer than 80 characters;
this file has too much indentation with really long expressions
to break all those lines now

Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
---
 fs/udf/super.c |  295 +++
 1 files changed, 166 insertions(+), 129 deletions(-)

diff --git a/fs/udf/super.c b/fs/udf/super.c
index 4360c7a..57788f1 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -33,8 +33,8 @@
  *  10/17/98  added freespace count for "df"
  *  11/11/98 gr   added novrs option
  *  11/26/98 dgb  added fileset,anchor mount options
- *  12/06/98 blf  really hosed things royally. vat/sparing support. sequenced 
vol descs
- *rewrote option handling based on isofs
+ *  12/06/98 blf  really hosed things royally. vat/sparing support. sequenced
+ *vol descs. rewrote option handling based on isofs
  *  12/20/98  find the free space bitmap (if it exists)
  */
 
@@ -116,7 +116,7 @@ static struct kmem_cache *udf_inode_cachep;
 static struct inode *udf_alloc_inode(struct super_block *sb)
 {
struct udf_inode_info *ei;
-   ei = (struct udf_inode_info *)kmem_cache_alloc(udf_inode_cachep, 
GFP_KERNEL);
+   ei = kmem_cache_alloc(udf_inode_cachep, GFP_KERNEL);
if (!ei)
return NULL;
 
@@ -561,47 +561,52 @@ static int udf_vrs(struct super_block *sb, int silent)
 
/* Look for ISO  descriptors */
vsd = (struct volStructDesc *)(bh->b_data +
-  (sector & (sb->s_blocksize - 
1)));
+ (sector & (sb->s_blocksize - 1)));
 
if (vsd->stdIdent[0] == 0) {
brelse(bh);
break;
-   } else if (!strncmp(vsd->stdIdent, VSD_STD_ID_CD001, 
VSD_STD_ID_LEN)) {
+   } else if (!strncmp(vsd->stdIdent, VSD_STD_ID_CD001,
+   VSD_STD_ID_LEN)) {
iso9660 = sector;
switch (vsd->structType) {
case 0:
udf_debug("ISO9660 Boot Record found\n");
break;
case 1:
-   udf_debug
-   ("ISO9660 Primary Volume Descriptor 
found\n");
+   udf_debug("ISO9660 Primary Volume Descriptor "
+ "found\n");
break;
case 2:
-   udf_debug
-   ("ISO9660 Supplementary Volume Descriptor 
found\n");
+   udf_debug("ISO9660 Supplementary Volume "
+ "Descriptor found\n");
break;
case 3:
-   udf_debug
-   ("ISO9660 Volume Partition Descriptor 
found\n");
+   udf_debug("ISO9660 Volume Partition Descriptor "
+ "found\n");
break;
case 255:
-   udf_debug
-   ("ISO9660 Volume Descriptor Set Terminator 
found\n");
+   udf_debug("ISO9660 Volume Descriptor Set "
+ "Terminator found\n");
break;
default:
udf_debug("ISO9660 VRS (%u) found\n",
  vsd->structType);
break;
}
-   } else if (!strncmp(vsd->stdIdent, VSD_STD_ID_BEA01, 
VSD_STD_ID_LEN)) {
-   } else if (!strncmp(vsd->stdIdent, VSD_STD_ID_TEA01, 
VSD_STD_ID_LEN)) {
+   } else if (!strncmp(vsd->stdIdent, VSD_STD_ID_BEA01,
+   VSD_STD_ID_LEN))
+   ; /* nothing */
+   else if (!strncmp(vsd->stdIdent, VSD_STD_ID_TEA01,
+   VSD_STD_ID_LEN)) {
brelse(bh);
break;
-   } else if (!strncmp(vsd->stdIdent, VSD_STD_ID_NSR02, 
VSD_STD_ID_LEN)) {
+   } else if (!strncmp(vsd->stdIdent, VSD_STD_ID_NSR02,
+   VSD_STD_ID_LEN))
nsr02 =

Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM

[Carlos Corbacho]

On Sunday 23 December 2007 23:12:47 H. Peter Anvin wrote:
> Rafael J. Wysocki wrote:
> > On Sunday, 23 of December 2007, Linus Torvalds wrote:
> >> On Sun, 23 Dec 2007, Rafael J. Wysocki wrote:
> >>> The patch is fine by me, so if anyone has objections, please speak up.
> >>
> >> There is absolutely *no* way I will apply this in an -rc6 release.
> >>
> This is totally the wrong way to go about it.

Please disregard the patch anyway - my test system was still using the custom 
DSDT - it doesn't fix anything.

Regardless, Linus' patch in question (in combination with Rafael's suspend 
reordering work) still broke suspend, and the port 0x142E write is still the 
offender, so something is still not playing nice - I'm just now at a complete 
loss as to what.

(PNPACPI came to mind as a suspect, but even with that disabled, this board/ 
chipset still wedges on suspend).

-Carlos
-- 
E-Mail: [EMAIL PROTECTED]
Web: strangeworlds.co.uk
GPG Key ID: 0x23EE722D
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/6] udf: improve code related to super_block, was: udf: convert super_block macros to functions

[marcin . slusarz]

Hi
This patchset converts macros related to super_block into
functions. Besides that it fixes some sparse warnings (6th),
improves coding style (1st) and fixes error handling (4th).

Note that udf files has really long lines and these patches won't
validate by checkpatch. I'm going to do more cleanups later.

First version of this patchset had 24 patches: 
http://lkml.org/lkml/2007/12/22/150
01 didn't change
02 was dropped
03-17,20,21 was combined into one (with changes asked by Christoph Hellwig)
18 was slightly changed - function udf_sb_alloc_partition_maps was moved from 
udf_sb.h to super.c
19 didn't change
22,23 was combined into one and functions moved from udf_sb.h to super.c
24 didn't change

Marcin Slusarz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: do not stop/start devices in suspend/resume path: the SCSI case

[Stephane Ascoet]

Bjorn Helgaas a écrit :

Good.  It's not clear to me whether it is safe to leave devices
enabled while we sleep.  I don't see an actual problem, but there
might be something related to hotplug while we're asleep or something.
So I'll cc: some additional people who might have some insight.
Hi, is there a chance for SCSI sleeping being managed by ACPI(it seems 
to be the case for IDE)?


--
Bien cordialement, Stephane Ascoet, conseils pour que la technologie 
soit un progres respectueux de la vie.

Album photo:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue

[Benjamin Herrenschmidt]

> I've occasionally wondered if that spinlock needs to get split up, but
> for the amount of pain that could ensue, I can't imagine it ever being
> worthwhile.

Wondered the same thing and decided against it. I do have every now and
then some really crazy cases to deal with. One of them is the need to
use something like fixmap/kmap_atomic because a vendors makes 32 bits
CPUs that need 512MB of address space to map config space :-)

Ben.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue

[Benjamin Herrenschmidt]

On Mon, 2007-12-24 at 10:06 +1100, Benjamin Herrenschmidt wrote:
> On Sun, 2007-12-23 at 22:15 +0100, Martin Mares wrote:
> > Hello!
> > 
> > >  - During that probe, you set a flag if any device has capabilities that
> > > extend beyond 0xff.
> > 
> > Can this work?  The extended capabilities are not linked to the normal
> > ones in any way.
> 
> Yeah, well, you set a flag if you have extended capabilities. I don't
> have my spec at hand (or the code) but can't we know if there are any
> based on some non-ext field ?

Allright, I d/l the spec and you are right... 

Yet another massive Intel f*ckup in the definition of PCI... Argh.

So that means you can't automatically detect that there's potentially
stuff in the extended caps. You still can do the initial probe solely
with type1, that would work around the problem with MMCONFIG overlapping
sized BARs (ah, BAR sizing, yet another case where somebody at Intel
should rather have broken an arm that day).

I still don't believe much in the idea of drivers enabling MMCONFIG
though.
 
Ben.,
 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails

[Bjorn Helgaas]

On Sunday 23 December 2007 2:28:05 am Jean Delvare wrote:
> Le 23/12/2007, Bjorn Helgaas a écrit:
> >On Saturday 22 December 2007 4:21:41 am Jean Delvare wrote:
> >> >This patch makes the it87 driver request only the two ports used for
> >> > the Environment Controller device.
> >>
> >> The problem is that the IT87xxF chips do decode 4 ports (recent chips,
> >> 0x294-0x297) or 8 ports (older chips, 0x290-0x297), not 2 as the
> >> datasheets say. The ITE Super-I/O chips differ from the Winbond
> >> Super-I/O chips in this respect. The it87 driver only needs to access
> >> ports 0x295 and 0x296, true, but the device itself decodes more
> >> addresses than that. So, with this proposed patch, ports which are busy
> >> will be shown as being free. This pretty much voids the point of
> >> resource declarations, doesn't it? This might not cause too much
> >> trouble in practice, but to me this still looks like the wrong way to
> >> go.
> >
> >Yes, all the ports decoded by the chip should certainly be reserved,
> >but I think the entire range should be reserved at a higher level,
> >like the PNP core, and the driver should reserve only the ports it
> >uses.  Then the entire range is reserved even if there is no driver
> >or the driver is not loaded.
>
> The problem is that the it87 driver is used on a variety of motherboards,
> some where the hardware monitoring device I/O ports are reserved by the
> BIOS, some where they aren't. How am I supposed to deal with this?

I assume you mean some boards describe those ports in ACPI, and some
don't?  I think the ideal solution would be to figure out how the
BIOS writers intended the device to be used, and do that.  But the
documentation may be lacking, and it degenerates into an OEM-specific
mess.  Second-best seems like a PNP quirk that pokes enough to determine
that a Super I/O device is present, and then reserves resources for
it.  Then we avoid the collision even if it87 isn't present.

> >That's the approach we use for PCI, e.g.,
> >
> >  e810-e81f : :00:08.0  <-- reserved by PCI core
> >e810-e8102fff : CS46xx_BA1_data0<-- reserved by driver
> >e811-e81137ff : CS46xx_BA1_data1
> >e812-e8126fff : CS46xx_BA1_pmem
> >e813-e81300ff : CS46xx_BA1_reg
>
> PCI is an entirely different beast. With PCI you know the PCI device ID
> that is associated with the resources, and for a given device, the
> resources are always declared (if standard BARs are used) or never
> declared; there's no "may be". So it's much easier to handle the
> resources properly.

That's the way PNP is supposed to work, too (more about this below).

> >> The resource declarations made by these motherboard BIOSes are totally
> >> bogus. 0x290-0x29f is much larger than what the chip decodes.
> >> 0x290-0x294 is a subset that doesn't make any sense. The GA-K8N Ultra 9
> >> is even funnier with 0x295-0x314, which again doesn't correspond to
> >> anything real.
> >
> >I agree those declarations are probably wrong.  But at least they're
> >larger than required, so they should be safe.
>
> That's not really safe, no. They may overlap with other device resources
> and prevent those drivers from loading.

True.  If that happens, I think we definitely need some kind of DMI-
based quirk to fix the resources.  My points are (a) the quirk needs
to be at the PNP level; it can't be in a driver, and (b) I'm lazy and
would wait until a problem happens before implementing it, because I
know so little about PNP and the specific board, and by waiting, there's
a chance I'll learn enough to avoid a mistake :-)

> >> All these happen to not intersect with 0x295-0x296 but I
> >> wouldn't count on it. If Gigabyte (and possibly others) care that
> >> little about these declarations, pretty much anything could be seen. So
> >> while your proposed workaround happens to fix the problem at hand, it is
> >> not really correct technically, and could break again soon.
> >>
> >> I'd rather fix the problem at its source, or, as fixing it as the source
> >> isn't very realistic in this case, as near of the source as possible.
> >> That would mean DMI-based quirks for the affected motherboards, that
> >> would discard or adjust the bogus resource declarations.
> >
> >Well, I think the driver change *is* correct, assuming that the
> >entire range can be reserved at a higher level.  In this case,
> >it is, via a PNP0C02 device.
>
> As I wrote above, the problem is that you can't assume that. Some
> motherboards do declare the range at PNP level but some don't. That's
> the reason why the it87 driver (and most other hwmon drivers for
> Super-I/O devices) do declare the I/O resource again.

The overlapping device problem is a subsystem problem, not a
driver problem.  We can't solve it in the driver because we can't
depend on the it87 driver being loaded.

> Another problem is how do I connect this specific I/O port range of the
> PNP0C02 device with the it87 driver? I am by far no PNP exper

Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM

[H. Peter Anvin]

Rafael J. Wysocki wrote:

On Sunday, 23 of December 2007, Linus Torvalds wrote:

On Sun, 23 Dec 2007, Rafael J. Wysocki wrote:

The patch is fine by me, so if anyone has objections, please speak up.

There is absolutely *no* way I will apply this in an -rc6 release.

The number of machines this will break is totally unknown. It might be 
zero. It might be hundreds.  We just don't know. We might hit another 
unlucky allocation that we just happened to avoid before.


I was rather thinking of putting it into -mm for some time and target for
2.6.25 if possible.

If it breaks systems, we can always revert before 2.6.25 final.



This is totally the wrong way to go about it.

Instead, it should detect this particular chipset and reserve relevant 
ports.  Even better would be if we can find out what reserves these 
ports and mark it as a quirk.


That being said, I have seen other chipsets allocate ports in the low 
0x1XXX range using non-BAR methods.  They *should* reserve them in ACPI, 
of course.


-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/63] ide-cd: redux

[Bartlomiej Zolnierkiewicz]

On Sunday 23 December 2007, Borislav Petkov wrote:
> On Fri, Dec 21, 2007 at 08:57:49PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > On Thursday 20 December 2007, Borislav Petkov wrote:
> > > On Thu, Dec 20, 2007 at 01:48:49AM +0100, Bartlomiej Zolnierkiewicz wrote:
> > > Hi Bart,
> > > Hi all,
> > > 
> > > > PS ide-cd Maintainer position is still open...
> > > i'd like to take that position if nobody objects. I've done some work 
> > > around the
> > > kernel here and there and i think its time for me to get serious.
> > 
> > Great!
> > 
> > Please send me a patch for MAINTAINERS file updating ide-cd entry.
> 
> Sure, there it is:
> 
> ---
> 
> Reopen ide-cd for maintainership.
> 
> Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>

applied, thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.24-rc6-mm1

[H. Peter Anvin]

Rafael J. Wysocki wrote:

On Sunday, 23 of December 2007, Andrew Morton wrote:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc6/2.6.24-rc6-mm1/

- This kernel doesn't work on i386!

  It oopses late in boot due to an unrevertable change (e3c1b141) in git-x86
  which I stared at for a while then I ran out of time and gave up.

  I would have just abandoned this release until it was fixed but I'll be
  largely offline for ten days starting tomorrow.

  The culprits have been notified and hopefully we'll have a patch for
  hot-fixes/ tomorrow.

  x86_64 and powerpc work OK though.


Well it doesn't build on x86-64 for me:

  CHK include/linux/compile.h
  CC  arch/x86/ia32/../../../fs/compat_binfmt_elf.o
Assembler messages:
Fatal error: can't create arch/x86/ia32/../../../fs/.tmp_compat_binfmt_elf.o: 
No such file or directory
make[2]: *** [arch/x86/ia32/../../../fs/compat_binfmt_elf.o] Error 2

I will post the .config if anyone is interested.



It's a Kbuild race -- if you keep re-building it will eventually build 
the right file.


Not excusable, but that's what's going on.

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] ide: add ide_dump_identify() debug helper

[Bartlomiej Zolnierkiewicz]

* Add ide_dump_identify() debug helper for dumping raw identify data in
  the hdparm friendly format (== the identify data can be extracted from
  dmesg output and passed to hdparm --Istdin).

* Dump identify data in ide-probe.c::do_identify() if DEBUG is enabled.

Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
 drivers/ide/ide-probe.c |4 
 include/linux/ide.h |5 +
 2 files changed, 9 insertions(+)

Index: b/drivers/ide/ide-probe.c
===
--- a/drivers/ide/ide-probe.c
+++ b/drivers/ide/ide-probe.c
@@ -129,6 +129,10 @@ static inline void do_identify (ide_driv
 
drive->id_read = 1;
local_irq_enable();
+#ifdef DEBUG
+   printk(KERN_INFO "%s: dumping identify data\n", drive->name);
+   ide_dump_identify((u8 *)id);
+#endif
ide_fix_driveid(id);
 
 #if defined (CONFIG_SCSI_EATA_PIO) || defined (CONFIG_SCSI_EATA)
Index: b/include/linux/ide.h
===
--- a/include/linux/ide.h
+++ b/include/linux/ide.h
@@ -1291,6 +1291,11 @@ extern struct bus_type ide_bus_type;
 #define ide_id_has_flush_cache_ext(id) \
(((id)->cfs_enable_2 & 0x2400) == 0x2400)
 
+static inline void ide_dump_identify(u8 *id)
+{
+   print_hex_dump(KERN_INFO, "", DUMP_PREFIX_NONE, 16, 2, id, 512, 0);
+}
+
 static inline int hwif_to_node(ide_hwif_t *hwif)
 {
struct pci_dev *dev = hwif->pci_dev;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] ide-{floppy,tape}: remove debug code for dumping identify data

[Bartlomiej Zolnierkiewicz]

IDE core supports dumping raw identify data in hdparm friendly format now
so verbose identify dumping in ide-{floppy,tape}.c device drivers (done iff
IDE{FLOPPY,TAPE}_DEBUG_INFO is defined to '1' and it is '0' by default)
is no longer nedeed.

Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
 drivers/ide/ide-floppy.c |   50 ---
 drivers/ide/ide-tape.c   |   59 ---
 2 files changed, 109 deletions(-)

Index: b/drivers/ide/ide-floppy.c
===
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -1658,7 +1658,6 @@ static int idefloppy_identify_device (id
 {
struct idefloppy_id_gcw gcw;
 #if IDEFLOPPY_DEBUG_INFO
-   u16 mask,i;
char buffer[80];
 #endif /* IDEFLOPPY_DEBUG_INFO */
 
@@ -1705,55 +1704,6 @@ static int idefloppy_identify_device (id
default: sprintf(buffer, "Reserved");break;
}
printk(KERN_INFO "Command Packet Size: %s\n", buffer);
-   printk(KERN_INFO "Model: %.40s\n",id->model);
-   printk(KERN_INFO "Firmware Revision: %.8s\n",id->fw_rev);
-   printk(KERN_INFO "Serial Number: %.20s\n",id->serial_no);
-   printk(KERN_INFO "Write buffer size(?): %d bytes\n",id->buf_size*512);
-   printk(KERN_INFO "DMA: %s",id->capability & 0x01 ? "Yes\n":"No\n");
-   printk(KERN_INFO "LBA: %s",id->capability & 0x02 ? "Yes\n":"No\n");
-   printk(KERN_INFO "IORDY can be disabled: %s",id->capability & 0x04 ? 
"Yes\n":"No\n");
-   printk(KERN_INFO "IORDY supported: %s",id->capability & 0x08 ? 
"Yes\n":"Unknown\n");
-   printk(KERN_INFO "ATAPI overlap supported: %s",id->capability & 0x20 ? 
"Yes\n":"No\n");
-   printk(KERN_INFO "PIO Cycle Timing Category: %d\n",id->tPIO);
-   printk(KERN_INFO "DMA Cycle Timing Category: %d\n",id->tDMA);
-   printk(KERN_INFO "Single Word DMA supported modes:\n");
-   for (i=0,mask=1;i<8;i++,mask=mask << 1) {
-   if (id->dma_1word & mask)
-   printk(KERN_INFO "   Mode %d%s\n", i,
-   (id->dma_1word & (mask << 8)) ? " (active)" : "");
-   }
-   printk(KERN_INFO "Multi Word DMA supported modes:\n");
-   for (i=0,mask=1;i<8;i++,mask=mask << 1) {
-   if (id->dma_mword & mask)
-   printk(KERN_INFO "   Mode %d%s\n", i,
-   (id->dma_mword & (mask << 8)) ? " (active)" : "");
-   }
-   if (id->field_valid & 0x0002) {
-   printk(KERN_INFO "Enhanced PIO Modes: %s\n",
-   id->eide_pio_modes & 1 ? "Mode 3":"None");
-   if (id->eide_dma_min == 0)
-   sprintf(buffer, "Not supported");
-   else
-   sprintf(buffer, "%d ns",id->eide_dma_min);
-   printk(KERN_INFO "Minimum Multi-word DMA cycle per word: %s\n", 
buffer);
-   if (id->eide_dma_time == 0)
-   sprintf(buffer, "Not supported");
-   else
-   sprintf(buffer, "%d ns",id->eide_dma_time);
-   printk(KERN_INFO "Manufacturer\'s Recommended Multi-word cycle: 
%s\n", buffer);
-   if (id->eide_pio == 0)
-   sprintf(buffer, "Not supported");
-   else
-   sprintf(buffer, "%d ns",id->eide_pio);
-   printk(KERN_INFO "Minimum PIO cycle without IORDY: %s\n",
-   buffer);
-   if (id->eide_pio_iordy == 0)
-   sprintf(buffer, "Not supported");
-   else
-   sprintf(buffer, "%d ns",id->eide_pio_iordy);
-   printk(KERN_INFO "Minimum PIO cycle with IORDY: %s\n", buffer);
-   } else
-   printk(KERN_INFO "According to the device, fields 64-70 are not 
valid.\n");
 #endif /* IDEFLOPPY_DEBUG_INFO */
 
if (gcw.protocol != 2)
Index: b/drivers/ide/ide-tape.c
===
--- a/drivers/ide/ide-tape.c
+++ b/drivers/ide/ide-tape.c
@@ -4291,9 +4291,6 @@ static int idetape_identify_device (ide_
 {
struct idetape_id_gcw gcw;
struct hd_driveid *id = drive->id;
-#if IDETAPE_DEBUG_INFO
-   unsigned short mask,i;
-#endif /* IDETAPE_DEBUG_INFO */
 
if (drive->id_read == 0)
return 1;
@@ -4333,62 +4330,6 @@ static int idetape_identify_device (ide_
case 1: printk("16 bytes\n");break;
default: printk("Reserved\n");break;
}
-   printk(KERN_INFO "ide-tape: Model: %.40s\n",id->model);
-   printk(KERN_INFO "ide-tape: Firmware Revision: %.8s\n",id->fw_rev);
-   printk(KERN_INFO "ide-tape: Serial Number: %.20s\n",id->serial_no);
-   printk(KERN_INFO "ide-tape: Write buffer size: %d 
bytes\n",id->buf_size*512);
-   printk(KERN_INFO "ide-tape: DMA: %s",id->capability & 0x01 ? 
"Yes

Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue

[Benjamin Herrenschmidt]

On Sun, 2007-12-23 at 22:15 +0100, Martin Mares wrote:
> Hello!
> 
> >  - During that probe, you set a flag if any device has capabilities that
> > extend beyond 0xff.
> 
> Can this work?  The extended capabilities are not linked to the normal
> ones in any way.

Yeah, well, you set a flag if you have extended capabilities. I don't
have my spec at hand (or the code) but can't we know if there are any
based on some non-ext field ?

Ben.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] scsi: Use new __dma_buffer to align sense buffer in scsi_cmnd

[Benjamin Herrenschmidt]

> This has the potential of leaving a big fat ugly hole in the middle of 
> scsi_cmnd. I would suggest of *just* moving the sense_buffer array to be
> the *first member* of struct scsi_cmnd. The command itself is already cache
> aligned, allocated by the proper flags to it's slab. And put a fat comment
> near it's definition.

The hole would only be present on non coherent architectures though. We
also still need the padding after the sense_buffer. But yeah, moving the
sense buffer to first position would diminish the size of the hole I
suppose.

> This is until a proper fix is sent. I have in my Q a proposition for a 
> more prominent solution, which I will send next month. Do to short comings
> in the sense handling and optimizations, but should definitely cover this
> problem.
> 
> The code should have time to be discussed and tested, so it is only 2.6.26
> material. For the duration of the 2.6.25 kernel we can live with a reorder
> of scsi_cmnd members, if it solves such a grave bug for some ARCHs.

Re-oreder isn't enough. We need both re-order and the __dma_buffer
annotation to ensure proper padding. Some archs have 64 or even 128
bytes cache line size.

I agree that in the long run, a better solution should be done involving
reworking the way the sense buffer is allocated. I started modifying the
EH code to kmalloc it, but it gets very messy with the current interface
between drivers and EH. I still have some patches around I can send,
though some drivers need fixing (error handling on kmalloc failure).
James seem to have a better idea of pre-allocating sense buffers per
host based on how many they can have in flight which I haven't looked
at.

Ben.

> Boaz
> 
> [RFD below]
> My proposed solution will be has follows:
> 
>  1. Since the scsi protocol mandates an immediate REQUEST_SENSE after an error
> in effect the Q is frozen until the REQUEST_SENSE command returns.
> 
>  2. The scsi-ml needs the sense buffer for its normal operation, independent 
> from the ULD's request of the sence_buffer or not at request->sense. But
> in effect, 90% of all scsi-requests come with ULD's allocated buffer for
> sense, that is copied to, on command completion.
> 
>  3. 99% of all commands complete successfully, so if an optimization is 
> proposed for the successful case, sacrificing a few cycles for the error
> case than thats a good thing.
> 
>  My suggestion is to have a per Q, driver-overridable, sense buffer that is 
>  DMAed/written to by drivers. At the end of the REQUEST_SENSE command one
>  of 2 things will be done. Either copy the sense to the ULD's supplied buffer,
>  or if not available, allocate one from a dedicated mem_cache pool.

I think that's pretty much was James was proposing indeed.

>  So we are completely saving 92 bytes from scsi_cmnd by replacing the buffer
>  with a pointer. We can always read the sense into a per Q buffer. And 10% of
>  %1 of the times we will need to allocate a sense buffer from a dedicated 
> mem_cache
>  I would say thats a nice optimization.
> 
>  The changes to scsi_error/scsi_cmnd and friends, is pretty strait forward. 
> But
>  it depends on a conversion of 4/5 drivers to the new scsi_eh API for 
>  REQUEST_SENSE. I have only converted these drivers that interfered with the 
> accessors
>  effort + 1 other places. But there are a few more places that are not 
> converted.
>  Once done. The implementation can easily change with no affect on drivers.
> 
>  The reason I've started with this work is because the SCSI standard permits 
> up
>  to 260 bytes of sense, which you guest right, is needed by the OSD command 
> set.
> 
> Boaz

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Build breakage on powerpc with 2.6.24-rc6-mm1

[Balbir Singh]

Hi,

I see the following error with the iseries_veth driver in 2.6.24-rc6-mm1

drivers/net/iseries_veth.c: In function ‘veth_init_connection’:
drivers/net/iseries_veth.c:818: warning: unused variable ‘rc’
drivers/net/iseries_veth.c: In function ‘veth_probe_one’:
drivers/net/iseries_veth.c:1086: error: ‘veth_port_ktypeq’ undeclared
(first use in this function)
drivers/net/iseries_veth.c:1086: error: (Each undeclared identifier is
reported only once
drivers/net/iseries_veth.c:1086: error: for each function it appears
in.)
make[2]: *** [drivers/net/iseries_veth.o] Error 1
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2

Here's a patch, compile tested to fix the compilation problem


Remove unused variable rc and fix a typo, veth_port_type was called
veth_port_typeq

Signed-off-by: Balbir Singh <[EMAIL PROTECTED]>
---

 drivers/net/iseries_veth.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff -puN drivers/net/iseries_veth.c~fix-iseries-veth-driver 
drivers/net/iseries_veth.c
--- linux-2.6.24-rc6/drivers/net/iseries_veth.c~fix-iseries-veth-driver 
2007-12-24 03:59:35.0 +0530
+++ linux-2.6.24-rc6-balbir/drivers/net/iseries_veth.c  2007-12-24 
04:02:31.0 +0530
@@ -815,7 +815,7 @@ static int veth_init_connection(u8 rlp)
 {
struct veth_lpar_connection *cnx;
struct veth_msg *msgs;
-   int i, rc;
+   int i;
 
if ( (rlp == this_lp)
 || ! HvLpConfig_doLpsCommunicateOnVirtualLan(this_lp, rlp) )
@@ -1083,7 +1083,7 @@ static struct net_device * __init veth_p
return NULL;
}
 
-   kobject_init(&port->kobject, &veth_port_ktypeq);
+   kobject_init(&port->kobject, &veth_port_ktype);
if (0 != kobject_add(&port->kobject, &dev->dev.kobj, "veth_port"))
veth_error("Failed adding port for %s to sysfs.\n", dev->name);
 
_

-- 
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 00/20] VM pageout scalability improvements

[Balbir Singh]

Rik van Riel wrote:
> On Sun, 23 Dec 2007 01:57:32 +0530
> Balbir Singh <[EMAIL PROTECTED]> wrote:
>> Rik van Riel wrote:
>>> On large memory systems, the VM can spend way too much time scanning
>>> through pages that it cannot (or should not) evict from memory. Not
>>> only does it use up CPU time, but it also provokes lock contention
>>> and can leave large systems under memory presure in a catatonic state.
>> I remember you mentioning that by large memory systems you mean systems
>> with at-least 128GB, does this definition still hold?
> 
> It depends on the workload.  Certain test cases can wedge the
> VM with as little as 16GB of RAM.  Other workloads cause trouble
> at 32 or 64GB, with the system sometimes hanging for several
> minutes, all the CPUs in the pageout code and no actual swap IO.
> 

Interesting, I have not run into it so far. But I have smaller machines,
typically 4-8GB.

> On systems of 128GB and more, we have seen systems hang in the
> pageout code overnight, without deciding what to swap out.
> 
>>> This patch series improves VM scalability by:
>>>
>>> 1) making the locking a little more scalable
>>>
>>> 2) putting filesystem backed, swap backed and non-reclaimable pages
>>>onto their own LRUs, so the system only scans the pages that it
>>>can/should evict from memory
>>>
>>> 3) switching to SEQ replacement for the anonymous LRUs, so the
>>>number of pages that need to be scanned when the system
>>>starts swapping is bound to a reasonable number
>>>
>>> The noreclaim patches come verbatim from Lee Schermerhorn and
>>> Nick Piggin.  I have not taken a detailed look at them yet and
>>> all I have done is fix the rejects against the latest -mm kernel.
>> Is there a consolidate patch available, it makes it easier to test.
> 
> I will make a big patch available with the next version.  I have
> to upgrade my patch set to newer noreclaim patches from Lee and
> add a few small cleanups elsewhere.
> 

That would be nice. I'll try and help out by testing the patches and
running them

>>> I am posting this series now because I would like to get more
>>> feedback, while I am studying and improving the noreclaim patches
>>> myself.
>> What kind of tests show the problem? I'll try and review and test the code.
> 
> The easiest test possible simply allocates a ton of memory and
> then touches it all.  Enough memory that the system needs to go
> into swap.
> 
> Once memory is full, you will see the VM scan like mad, with a
> big CPU spike (clearing the referenced bits off all pages) before
> it starts swapping out anything.  That big CPU spike should be
> gone or greatly reduced with my patches.
> 
> On really huge systems, that big CPU spike can be enough for one
> CPU to spend so much time in the VM that all the other CPUs join
> it, and the system goes under in a big lock contention fest.
> 
> Besides, even single threadedly clearing the referenced bits on
> 1TB worth of memory can't result in acceptable latencies :)
> 
> In the real world, users with large JVMs on their servers, which
> sometimes go a little into swap, can trigger this system.  All of
> the CPUs end up scanning the active list, and all pages have the
> referenced bit set.  Even if the system eventually recovers, it
> might as well have been dead.
> 
> Going into swap a little should only take a little bit of time.
> 

Very fascinating, so we need to scale better with larger memory.
I suspect part of the answer will lie with using large/huge pages.



-- 
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.24-rc6-mm1: suspend broken on HP nx6325 due to cpufreq changes

[Dave Jones]

On Sun, Dec 23, 2007 at 02:50:03PM -0800, Andrew Morton wrote:

 > > > - Someone broke suspend-to-RAM on the t61p again.  It just instantly 
 > > > resumes
 > > >   itself.
 > > 
 > > Suspend is also broken on my HP nx6325 (hangs hard in the last phase of
 > > suspend) and git-cpufreq.patch is responsible for that (as shown by 
 > > bisection).
 > > 
 > > Reverting git-cpufreq.patch makes suspend work again,
 > 
 > ah.  Thanks.

I'm not sure how this is 'new' breakage, because git-cpufreq hasn't changed
in a while, other than the integration of that missing #include diff
that sat in -mm.   Maybe some bad interaction with something else that
changed perhaps. *shrug*.

I'm on vacation until the new year, so I'm going out of my way not to look
at bugs for a change.  But I'm not ignoring this completely, I'll make a
note to look at it in January.
 
Dave

-- 
http://www.codemonkey.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Can't disconnect a USB sound device and connect another

[Victor Hahn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

... because it causes lsusb to freeze and gives me this in /var/log/messages:

Dec 23 23:27:04 cabrio kernel: usb 2-2: USB disconnect, address 5
Dec 23 23:27:04 cabrio kernel: PGD 110f2067 PUD 110f3067 PMD 0
Dec 23 23:27:04 cabrio kernel: CPU 0
Dec 23 23:27:04 cabrio kernel: Modules linked in: videodev v4l2_common 
v4l1_compat snd_rtctimer binfmt_misc rfcomm l2cap bluetooth capability 
commoncap ppdev powernow_k8 cpufreq_userspace cpufreq_stats cpufreq_powersave 
cpufreq_ondemand freq_table cpufreq_conservative video output sbs container 
dock ac battery ext3 jbd mbcache aes_x86_64 ipv6 it87 hwmon_vid parport_pc lp 
parport loop snd_mpu401 snd_mpu401_uart snd_usb_audio snd_pcm_oss 
snd_mixer_oss snd_pcm snd_seq_dummy snd_page_alloc snd_usb_lib snd_hwdep 
snd_seq_oss analog gameport snd_seq_midi snd_rawmidi snd_seq_midi_event 
snd_seq snd_timer snd_seq_device snd psmouse button soundcore serio_raw 
i2c_nforce2 k8temp i2c_core pcspkr af_packet shpchp pci_hotplug evdev xfs 
sha256 twofish_x86_64 twofish_common cbc blkcipher sg ide_cd cdrom sd_mod 
usbhid hid sata_nv 8139too floppy ata_generic 8139cp mii libata scsi_mod 
amd74xx ide_core forcedeth ehci_hcd ohci_hcd usbcore dm_crypt dm_mirror 
dm_snapshot dm_mod thermal processor fan fuse
Dec 23 23:27:04 cabrio kernel: Pid: 2052, comm: khubd Not tainted 2.6.23.11 #1
Dec 23 23:27:04 cabrio kernel: RIP: 0010:[_end+130488219/2130651808]  
[_end+130488219/2130651808] :snd:snd_ctl_dev_disconnect+0x6b/0xb0
Dec 23 23:27:04 cabrio kernel: RSP: 0018:810037bfdc40  EFLAGS: 00010282
Dec 23 23:27:04 cabrio kernel: RAX:  RBX: 00100100 
RCX: 0018
Dec 23 23:27:04 cabrio kernel: RDX: 00020004 RSI: 001d 
RDI: 810013e98c08
Dec 23 23:27:04 cabrio kernel: RBP: 8100394631a8 R08: 810037bfc000 
R09: 
Dec 23 23:27:04 cabrio kernel: R10:  R11: 88281910 
R12: 810039463000
Dec 23 23:27:04 cabrio kernel: R13: 810039463168 R14:  
R15: 810039463000
Dec 23 23:27:04 cabrio kernel: FS:  2b24912551e0() GS:80533000
() knlGS:f74b16c0
Dec 23 23:27:04 cabrio kernel: CS:  0010 DS: 0018 ES: 0018 CR0: 
8005003b
Dec 23 23:27:04 cabrio kernel: CR2: 00100100 CR3: 110f1000 
CR4: 06e0
Dec 23 23:27:04 cabrio kernel: DR0:  DR1:  
DR2: 
Dec 23 23:27:04 cabrio kernel: DR3:  DR6: 0ff0 
DR7: 0400
Dec 23 23:27:04 cabrio kernel: Process khubd (pid: 2052, threadinfo 
810037bfc000, task 81003d67d0c0)
Dec 23 23:27:04 cabrio kernel: Stack:   810038850d00 
810039463000 810039463150
Dec 23 23:27:04 cabrio kernel:   88281e69 
810038850d00 882821ac
Dec 23 23:27:04 cabrio kernel:    
810039463000 8100394631e0
Dec 23 23:27:04 cabrio kernel: Call Trace:
Dec 23 23:27:04 cabrio kernel:  
[_end+130500873/2130651808] :snd:snd_device_disconnect+0x59/0x90
Dec 23 23:27:04 cabrio kernel:  
[_end+130501708/2130651808] :snd:snd_device_disconnect_all+0x3c/0x70
Dec 23 23:27:04 cabrio kernel:  
[_end+130481675/2130651808] :snd:snd_card_disconnect+0x15b/0x1a0
Dec 23 23:27:04 cabrio kernel:  
[_end+131093678/2130651808] :snd_usb_audio:usb_audio_disconnect+0xae/0x1a0
Dec 23 23:27:04 cabrio kernel:  
[_end+128211869/2130651808] :usbcore:usb_unbind_interface+0x6d/0xe0
Dec 23 23:27:04 cabrio kernel:  [__device_release_driver+130/192] 
__device_release_driver+0x82/0xc0
Dec 23 23:27:04 cabrio kernel:  [device_release_driver+51/96] 
device_release_driver+0x33/0x60
Dec 23 23:27:04 cabrio kernel:  [bus_remove_device+118/176] 
bus_remove_device+0x76/0xb0
Dec 23 23:27:04 cabrio kernel:  [device_del+417/736] device_del+0x1a1/0x2e0
Dec 23 23:27:04 cabrio kernel:  
[_end+128198657/2130651808] :usbcore:usb_disable_device+0x91/0x110
Dec 23 23:27:04 cabrio kernel:  
[_end+128179466/2130651808] :usbcore:usb_disconnect+0xaa/0x150
Dec 23 23:27:04 cabrio kernel:  
[_end+128181649/2130651808] :usbcore:hub_thread+0x401/0xe30
Dec 23 23:27:04 cabrio kernel:  [thread_return+87/1463] 
thread_return+0x57/0x5b7
Dec 23 23:27:04 cabrio kernel:  [autoremove_wake_function+0/48] 
autoremove_wake_function+0x0/0x30
Dec 23 23:27:04 cabrio kernel:  
[_end+128180624/2130651808] :usbcore:hub_thread+0x0/0xe30
Dec 23 23:27:04 cabrio kernel:  [kthread+75/128] kthread+0x4b/0x80
Dec 23 23:27:04 cabrio kernel:  [child_rip+10/18] child_rip+0xa/0x12
Dec 23 23:27:04 cabrio kernel:  [kthread+0/128] kthread+0x0/0x80
Dec 23 23:27:04 cabrio kernel:  [child_rip+0/18] child_rip+0x0/0x12
Dec 23 23:27:04 cabrio kernel:
Dec 23 23:27:04 cabrio kernel:
Dec 23 23:27:04 cabrio kernel: Code: 48 8b 03 0f 18 08 48 39 eb 75 ca 4c 89 ef 
e8 d2 35 fd f7 ba
Dec 23 23:27:04 cabrio kernel:  RSP 

Is there a way to exchange USB audio devices without rebooting?

Beste r

Re: 2.6.24-rc6-mm1: suspend broken on HP nx6325 due to cpufreq changes

[Andrew Morton]

On Sun, 23 Dec 2007 23:54:40 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> 
wrote:

> On Sunday, 23 of December 2007, Andrew Morton wrote:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc6/2.6.24-rc6-mm1/
> > 
> > - This kernel doesn't work on i386!
> > 
> >   It oopses late in boot due to an unrevertable change (e3c1b141) in git-x86
> >   which I stared at for a while then I ran out of time and gave up.
> > 
> >   I would have just abandoned this release until it was fixed but I'll be
> >   largely offline for ten days starting tomorrow.
> > 
> >   The culprits have been notified and hopefully we'll have a patch for
> >   hot-fixes/ tomorrow.
> > 
> >   x86_64 and powerpc work OK though.
> > 
> > - git-block is dropped due to more conflicts that I'm prepared to repair
> >   with git-scsi-misc
> > 
> > - git-perfmon is dropped due to conflicts with git-x86
> > 
> > - git-kgdb is dropped due to conflicts with git-x86
> > 
> > - git-newsetup is dropped due to conflicts with git-x86
> > 
> > - Andi's x86 quilt tree is dropped due to conflicts with git-x86
> > 
> > - Someone broke suspend-to-RAM on the t61p again.  It just instantly resumes
> >   itself.
> 
> Suspend is also broken on my HP nx6325 (hangs hard in the last phase of
> suspend) and git-cpufreq.patch is responsible for that (as shown by 
> bisection).
> 
> Reverting git-cpufreq.patch makes suspend work again,

ah.  Thanks.

> although it still is a
> bit flaky (it takes well more than 5 seconds to suspend and the sound adapter
> doesn't work right after the resume, but it starts to work again about 10s
> later).

hm.  There have been some suspend changes in the alsa tree.

And yes, I noticed that susped has become slower too - looks like abot ten
seconds, which is a pretty significant usability irritant.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Fwd: Re: [PATCH 0/5]PCI: x86 MMCONFIG]

[Loic Prylli]

On 12/23/2007 3:55 PM, Matthew Wilcox wrote:
> On Sun, Dec 23, 2007 at 03:16:24PM -0500, Loic Prylli wrote:
>   
>> I just realized one thing: the bar sizing code in pci_read_bases() (that
>> writes 0x in the bars) does not seem to disable the
>> PCI_COMMAND_MEM/PCI_COMMAND_IO bits in the cmd register before
>> manipulating the BARs. And it seems nobody else ensures they are
>> disabled at this point either (or am I missing something?).
>> 
>
> Right, we don't.  Ivan and Greg are convinced that doing so can break
> some machines.  
>   



 It might indeed be scary to suddenly change the command bits on some
old "Host bridges" and maybe other classes of bridges. I was too
optimistic about the triviality of the fix.


Still an obvious improvement to the pci_read_bases() code would be to
not try sizing non-existings BARs (that way if a device has no memory
bars, we never need to touch the mem-enable bit). In addition, if you
exclude Host bridges and other bridges from temporary mem-disabling
while sizing their BARs, then doing temp disabling for the remaining
devices looks less scary than the alternative (messing live with the
bars decoding range especially for regular devices integrated to the
main chipset).


It seems to me worth making that init code safer independantly of the
mmconfig issues.



> Now that contradicts some information we've been told before; can you
> post those traces?  That would argue in favour of disabling memspace
> when configuring BARs.
>   



Here is a trace where COMMAND/STATUS and 0x10 and 0x14 registers
accesses were captured. Comments in brackets are my interpretation of
what's happening. That was with windows 2003 64bit.


Loic



[ reset at 607 second]

[BIOS: read-status, COMMAND = 0 ]

626.442718:cfg-read:0x6.w=0x10
626.442805:cfg-write:0x4.w=0x0

[BIOS: sizing BAR0]

626.448325:cfg-read:0x10.l=0x8
626.448365:cfg-write:0x10.l=0xfffe
626.448439:cfg-read:0x10.l=0xff08
626.448493:cfg-write:0x10.l=0x8

[BIOS: sizing non-existent BAR1]

626.448552:cfg-read:0x14.l=0x0
626.448591:cfg-write:0x14.l=0xfffe
626.448647:cfg-read:0x14.l=0x0
626.448687:cfg-write:0x14.l=0x0

[BIOS: sizing BAR0]

626.449596:cfg-read:0x10.l=0x8
626.449635:cfg-write:0x10.l=0xfffe
626.449710:cfg-read:0x10.l=0xff08
626.449764:cfg-write:0x10.l=0x8

[BIOS: sizing non-existent BAR1]

626.449832:cfg-read:0x14.l=0x0
626.449872:cfg-write:0x14.l=0xfffe
626.449928:cfg-read:0x14.l=0x0
626.449967:cfg-write:0x14.l=0x0

[BIOS: sizing BAR0]


626.451822:cfg-read:0x10.l=0x8
626.451862:cfg-write:0x10.l=0xfffe
626.451936:cfg-read:0x10.l=0xff08
626.451990:cfg-write:0x10.l=0x8

[BIOS: sizing non-existent BAR1]

626.452058:cfg-read:0x14.l=0x0
626.452098:cfg-write:0x14.l=0xfffe
626.452154:cfg-read:0x14.l=0x0
626.452194:cfg-write:0x14.l=0x0


[BIOS: sizing and assigning BAR0]

626.454899:cfg-read:0x10.l=0x8
626.454939:cfg-write:0x10.l=0xfffe
626.455013:cfg-read:0x10.l=0xff08

626.455068:cfg-write:0x10.l=0x8
626.455138:cfg-write:0x10.l=0xfa00

[BIOS: sizing non-existent BAR1]

626.455211:cfg-read:0x14.l=0x0
626.455251:cfg-write:0x14.l=0xfffe
626.455307:cfg-read:0x14.l=0x0
626.455346:cfg-write:0x14.l=0x0


[BIOS: sizing and restoring BAR0]


628.024774:cfg-read:0x10.l=0xfa08
628.024831:cfg-write:0x10.l=0xfffe
628.024908:cfg-read:0x10.l=0xff08
628.024964:cfg-write:0x10.l=0xfa08

[BIOS: sizing non-existent BAR1]

628.025049:cfg-read:0x14.l=0x0
628.025091:cfg-write:0x14.l=0xfffe
628.025149:cfg-read:0x14.l=0x0
628.025190:cfg-write:0x14.l=0x0

[BIOS: clear status ]

628.025714:cfg-write:0x6.w=0x

[BIOS: enable SERR/IO+MEMORY+MASTER+SPECIAL+INVALIDATE ]
628.025788:cfg-write:0x4.w=0x11f

[BIOS: enable MEMORY+MASTER (after seeing IO/special/invalidate were
read-only 0) ]
629.028114:cfg-read:0x4.b=0x6
629.028160:cfg-write:0x4.b=0x6

[BIOS: read status, clear PARITY/SERR status bits ]
629.028490:cfg-read:0x7.b=0x0
629.028536:cfg-write:0x7.b=0xc1

[BIOS: enable PARITY detection ]
629.028818:cfg-read:0x4.b=0x6
629.028863:cfg-write:0x4.b=0x46

[BIOS: enable SERR (already enabled anyway) ]
629.028920:cfg-read:0x5.b=0x1
629.028966:cfg-write:0x5.b=0x1
629.032338:cfg-read:0x6.w=0x10


[ WINDOWS starting ]

661.965932:cfg-read:0x4.l=0x100146
661.965986:cfg-read:0x10.l=0xfa08
661.966040:cfg-read:0x14.l=0x0

662.112971:cfg-read:0x4.l=0x100146
662.113024:cfg-read:0x10.l=0xfa08
662.113078:cfg-read:0x14.l=0x0

662.155903:cfg-read:0x4.l=0x100146

662.156066:cfg-read:0x4.l=0x100146
662.156120:cfg-read:0x10.l=0xfa08
662.156174:cfg-read:0x14.l=0x0

662.156337:cfg-read:0x4.l=0x100146
662.156391:cfg-read:0x10.l=0xfa08
662.156445:cfg-read:0x14.l=0x0

[ WINDOWS: disable MEMORY + MASTER ]
662.156519:cfg-write:0x4.l=0x140

[ WINDOWS: size BAR0 and BAR1]
662.156588:cfg-write:0x10.l=0x
662.156662:cfg-write:0x14.l=0x
662.156755:cfg-read:0x4.l=0x100140
662.156809:cfg-read:0x10.l=0xff08
662.156863:cfg-read:0x14.l=0x0

[ WINDOWS: disable MEMORY + 

Re: 2.6.24-rc6-mm1: suspend broken on HP nx6325 due to cpufreq changes

[Rafael J. Wysocki]

On Sunday, 23 of December 2007, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc6/2.6.24-rc6-mm1/
> 
> - This kernel doesn't work on i386!
> 
>   It oopses late in boot due to an unrevertable change (e3c1b141) in git-x86
>   which I stared at for a while then I ran out of time and gave up.
> 
>   I would have just abandoned this release until it was fixed but I'll be
>   largely offline for ten days starting tomorrow.
> 
>   The culprits have been notified and hopefully we'll have a patch for
>   hot-fixes/ tomorrow.
> 
>   x86_64 and powerpc work OK though.
> 
> - git-block is dropped due to more conflicts that I'm prepared to repair
>   with git-scsi-misc
> 
> - git-perfmon is dropped due to conflicts with git-x86
> 
> - git-kgdb is dropped due to conflicts with git-x86
> 
> - git-newsetup is dropped due to conflicts with git-x86
> 
> - Andi's x86 quilt tree is dropped due to conflicts with git-x86
> 
> - Someone broke suspend-to-RAM on the t61p again.  It just instantly resumes
>   itself.

Suspend is also broken on my HP nx6325 (hangs hard in the last phase of
suspend) and git-cpufreq.patch is responsible for that (as shown by bisection).

Reverting git-cpufreq.patch makes suspend work again, although it still is a
bit flaky (it takes well more than 5 seconds to suspend and the sound adapter
doesn't work right after the resume, but it starts to work again about 10s
later).

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue

[Ivan Kokshaysky]

On Sun, Dec 23, 2007 at 10:15:10PM +0100, Martin Mares wrote:
> >  - During that probe, you set a flag if any device has capabilities that
> > extend beyond 0xff.
> 
> Can this work?  The extended capabilities are not linked to the normal
> ones in any way.

Good point.

OTOH, we *do* have a flag for the extended capabilities - dev->cfg_size.
Obviously, the pci probe *without* mmconfig will set it to 256 for *all*
devices.
So Linus' idea of enabling mmconfig per-device makes a lot of sense in the
end - if mmconfig works, it just sets dev->cfg_size to 4096.
Without bloating the struct pci_dev or screwing up innocent arches...

Ivan.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.24-rc5-mm 2/3] gpiolib: add Generic IRQ support for 16-bit PCA9539 GPIO expander

[David Brownell]

> From: eric miao <[EMAIL PROTECTED]>
> 
> This patch adds the generic IRQ support for the PCA9539 on-chip GPIOs.

This one bothers me a bit on some technical grounds.  One problem is
that these chips are not designed for reliable IRQ management, so no
matter what a driver does it can't deliver that.  The other is with
respect to what this code does.


As background, here's what the TI docs say about IRQ support on this
chip.  In this area the pca953x parts closely resemble pcf857x ones,
which I've looked at.  I can say that I haven't (yet?) happened
across boards that use the IRQ mechanism on those '857x parts ...

| Interrupt (INT) Output
|
| An interrupt is generated by any rising or falling edge of the port
| inputs in the input mode.

That's an issue.  Your code is trying to emulate all three edge trigger
modes instead of just "both edges".  I've come to believe such emulation
is not a good thing, since it necessarily loses in some cases.


|   After time, T(iv), the signal INT is valid. 
| Resetting the interrupt circuit is achieved when data on the port is
| changed to the original setting,

Another issue.  The IRQ will effectively clear by itself, leaving
no record of exactly what triggered the IRQ. 

So IRQs on this chip are problematic at the hardware level, except
as a lossy "something changed" notification to help avoid polling
the chip for the current status of input pins.


|data is read from the port that
| generated the interrupt, or in a Stop event. 

Another issue.  IRQ pulses can be arbitrarily short -- maybe too short
to register at the host, given glitch removal circuitry! -- when a
host is performing I/O to the chip while the signal is being raised.


|   Resetting occurs in the 
| read mode at the acknowledge (ACK) bit or not acknowledge (NACK) bit
| after the falling edge of the SCL signal. In a Stop event, INT is cleared
| after the rising edge of SDA. Interrupts that occur during the ACK or
| NACK clock pulse can be lost (or be very short) due to the resetting
| of the interrupt during this pulse. Each change of the I/Os after
| resetting is detected and is transmitted as INT.
|
| Reading from or writing to another device does not affect the interrupt
| circuit, and a pin configured as an output cannot cause an interrupt.
| Changing an I/O from an output to an input may cause a false interrupt
| to occur if the state of the pin does not match the contents of the
| Input Port register. Because each 8-bit port is read independently, the
| interrupt caused by port 0 is not cleared by a read of port 1, or vice versa.
|
| INT has an open-drain structure and requires a pullup resistor to VCC.

Now, there *are* I2C GPIO expanders that have non-lossy IRQ support,
but these '857x and '953x parts don't seem to be in that category.


> ---
>  drivers/gpio/Kconfig   |   11 +++-
>  drivers/gpio/pca9539.c |  185 
> 
>  2 files changed, 195 insertions(+), 1 deletions(-)
> 
>   ...
>
> --- a/drivers/gpio/pca9539.c
> +++ b/drivers/gpio/pca9539.c

As to what this code does:


> @@ -155,6 +174,158 @@ static int pca9539_init_gpio(struct pca9539_chip *chip)
>   return gpiochip_add(gc);
>  }
> 
> +#ifdef CONFIG_GPIO_PCA9539_GENERIC_IRQ
> +/* FIXME: change to schedule_delayed_work() here if reading out of
> + * registers does not reflect the actual pin levels
> + */

Docs say reading the input registers does reflect current signal
levels -- no IRQ latches involved.  So that FIXME should go.


> +
> +static void pca9539_irq_work(struct work_struct *work)
> +{
> + struct pca9539_chip *chip;
> + uint16_t input, mask, rising, falling;
> + int ret, i;
> +
> + chip = container_of(work, struct pca9539_chip, irq_work);
> +
> + ret = pca9539_read_reg(chip, PCA9539_INPUT, &input);
> + if (ret < 0)
> + return;
> +
> + mask = (input ^ chip->last_input) & chip->irq_mask;
> + rising = (input & mask) & chip->irq_rising_edge;
> + falling = (~input & mask) & chip->irq_falling_edge;

As noted above, this stuff is all lossy.  You won't be able to
issue some IRQs that should be issued.

> +
> + irq_enter();

I thought irq_enter/irq_exit were intended to bracket hardirq
contexts?  This isn't a hardirq context... it's a task.


> +
> + for (i = 0; i < NR_PCA9539_GPIOS; i++) {
> + if ((rising | falling) & (1u << i)) {
> + int irq = chip->irq_start + i;
> + struct irq_desc *desc;
> +
> + desc = irq_desc + irq;
> + desc_handle_irq(irq, desc);

But desc_handle_irq() is an obsolete ARM-only call.  Instead,
generic_handle_irq() would be better. 

And I'm sure the loop itself can be streamlined ... calculate
the mask of which GPIOs you'll issue IRQs for, then ffs() to
quickly find the bits set in that mask.  Call that IRQ, clear

Re: 2.6.24-rc6-mm1

[Rafael J. Wysocki]

On Sunday, 23 of December 2007, Sam Ravnborg wrote:
> On Sun, Dec 23, 2007 at 02:53:34PM +0100, Rafael J. Wysocki wrote:
> > On Sunday, 23 of December 2007, Rafael J. Wysocki wrote:
> > > On Sunday, 23 of December 2007, Ingo Molnar wrote:
> > > > 
> > > > * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> > > > 
> > > > > Well it doesn't build on x86-64 for me:
> > > > > 
> > > > >   CHK include/linux/compile.h
> > > > >   CC  arch/x86/ia32/../../../fs/compat_binfmt_elf.o
> > > > > Assembler messages:
> > > > > Fatal error: can't create 
> > > > > arch/x86/ia32/../../../fs/.tmp_compat_binfmt_elf.o: No such file or 
> > > > > directory
> > > > > make[2]: *** [arch/x86/ia32/../../../fs/compat_binfmt_elf.o] Error 2
> > > > > 
> > > > > I will post the .config if anyone is interested.
> > > > 
> > > > yes, please send the .config.
> > > 
> > > Attached.
> > > 
> > > It also may be relevant that I compile the kernel with "make O=../build".
> > 
> > I ran the compilation once again and it worked.  Strange.
> Try to delete your fs/ directory in your output dir.
> Then I expect the same bug to surface again.

It does surface indeed.

> I guess it is because arch/x86/ia32/ is built before fs/ and
> gcc cannot create directories for the output files and
> it is the dependency files that triggers the error as this
> is the first file to be generated.

I think you are right.

Greetings,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM

[Rafael J. Wysocki]

On Sunday, 23 of December 2007, Linus Torvalds wrote:
> 
> On Sun, 23 Dec 2007, Rafael J. Wysocki wrote:
> > 
> > The patch is fine by me, so if anyone has objections, please speak up.
> 
> There is absolutely *no* way I will apply this in an -rc6 release.
> 
> The number of machines this will break is totally unknown. It might be 
> zero. It might be hundreds.  We just don't know. We might hit another 
> unlucky allocation that we just happened to avoid before.

I was rather thinking of putting it into -mm for some time and target for
2.6.25 if possible.

If it breaks systems, we can always revert before 2.6.25 final.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Boot time module loading problem

[Michael Buesch]

On Sunday 23 December 2007 20:39:18 Larry Finger wrote:
> With 2.6.24-rc5, a b43 user reports a problem at bootup. The b43 module, 
> which should be loaded by
> the ssb module, fails with the following type of message:
> 
> ssb: Sonics Silicon Backplane found on PCI device :0c:00.0
> b43: disagrees about version of symbol ssb_device_is_enabled
> b43: Unknown symbol ssb_device_is_enabled
> b43: disagrees about version of symbol ssb_pcicore_dev_irqvecs_enable
> b43: Unknown symbol ssb_pcicore_dev_irqvecs_enable
> b43: disagrees about version of symbol ssb_bus_may_powerdown
> b43: Unknown symbol ssb_bus_may_powerdown

This is a module versioning warning.
I think it's caused by a b43 compiled against a different
kernel tree than the currently running ssb module.
Different may mean that only a tiny little thing was changed, which
might not affect the API at all. modversion will complain then.

I don't use module versioning, so I can't help you how to fix this.
I'd simply suggest turning off module versioning.

-- 
Greetings Michael.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: tlb_finish_mmu() bogisity

[Linus Torvalds]

On Sun, 23 Dec 2007, Al Viro wrote:
>
> tlb->need_flush += &__get_cpu_var(quicklist)[0].nr_pages != 0;
> makes no sense whatsoever.  How the hell can you ever get the address of
> __get_cpu_var(quicklist)[0].nr_pages to be NULL?  Postfix operators have
> higher precedence than prefix ones, so that's
>   &(((__get_cpu_var(quicklist))[0]).nr_pages)
> 
> What did you intend here?  s/&//, perhaps?

I think that thing is bogus in other ways. It plays games with 
"needs_flush", just because it seems to want the generic code to then call 
"check_pgt_cache()", not because it actually wants any flushing to take 
place.

But we already call "check_pgt_cache()" there in tlb_finish_mmu() 
unconditionally, so I think the whole patch was utter crap.

Or is there any other reason going on here? That quicklist stuff has been 
totally broken, it's done too many totally invalid things to really be 
worth even keeping. We should get rid of that unmaintainable hack, and if 
it has a real performance upside, we should make it part of the *native* 
mmu-gather infrastructure, instead of maintaining it as some separate and 
buggy/unmaintainable piece-of-sh*t code.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue

[Martin Mares]

Hello!

>  - During that probe, you set a flag if any device has capabilities that
> extend beyond 0xff.

Can this work?  The extended capabilities are not linked to the normal
ones in any way.

Have a nice fortnight
-- 
Martin `MJ' Mares  <[EMAIL PROTECTED]>   
http://mj.ucw.cz/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
A bug in the code is worth two in the documentation.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue

[Benjamin Herrenschmidt]

> Are you prepared to guarantee that freely mixing mmconfig and type1 
> config accesses at runtime will always work, on all chipsets?  I'm 
> talking about silicon here, not kernel software.

We spinlock config space accesses. So the silicon will never see
simultaneous accesses, which is what I strongly suspect would be broken
in chipsets (asking for livelocks here).

Now there is the question of whether the silicon implements MMCONFIG
writes in some asynchronous way, in which case, there might be an issue
if you go bang the port right away but I very much doubt it.

Ben.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue

[Benjamin Herrenschmidt]

On Sat, 2007-12-22 at 21:00 -0800, Linus Torvalds wrote:
> 
> On Sat, 22 Dec 2007, Jeff Garzik wrote:
> > 
> > But regardless of problems, enabling should be done globally, not per
> > device...
> 
> I'm ok with trying the "globally" idea, but it has to be "globally but 
> only if absolutely required".
> 
> And quite frankly, how do you tell whether it's absolutely required or 
> not?
> 
> I have an idea: the drivers that really need it will do a "please enable 
> MMCONFIG, because I will need it" thing?

What about this approach:

 - At boot, MMCONFIG is disabled, you perform the initial probe of all
devices.

 - During that probe, you set a flag if any device has capabilities that
extend beyond 0xff.

 - Once the main probe pass is done (before drivers are hooked up, which
on PCI is a separate phase), if that flag has been set, you print a fat
warning (on peecee's, which are our main concern, this will generally be
visible on vga console), that you're about to enable MMCONFIG for this
device and if the machine crashes, send a bug report and boot with
nommconfig. Then, for each of those devices, attempt to re-read the
config space header with MMCONFIG, and compare to what is supposed to be
there (+/- irrelevant status bits). If that fails, warn and keep
MMCONFIG disabled.

At this point, you can decide to either keep MMCONFIG on/off on a
per-device basis (if a device has capabilities in the ext space, use
MMCONFIG for it). In that case, your proposed API is useful to
force-enabling MMCONFIG for a given device if there are no such
capabilities but the driver wants to force-enable. That case should be
extremely rare if existing at all

Or you can decide to keep the enable/disable global (if a single device
fails, don't enable MMCONFIG globally).

Ben.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Fwd: Re: [PATCH 0/5]PCI: x86 MMCONFIG]

[Matthew Wilcox]

On Sun, Dec 23, 2007 at 03:16:24PM -0500, Loic Prylli wrote:
> I just realized one thing: the bar sizing code in pci_read_bases() (that
> writes 0x in the bars) does not seem to disable the
> PCI_COMMAND_MEM/PCI_COMMAND_IO bits in the cmd register before
> manipulating the BARs. And it seems nobody else ensures they are
> disabled at this point either (or am I missing something?).

Right, we don't.  Ivan and Greg are convinced that doing so can break
some machines.  

> FWIW, to partially answer your last question, Windows does disable
> mem-space and/or IO-space when sizing the bars of a device (I have some
> traces of configuration-space-access taken on a window machine for one
> of the PCI busses).

Now that contradicts some information we've been told before; can you
post those traces?  That would argue in favour of disabling memspace
when configuring BARs.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Bug 9528] x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM

[Yinghai Lu]

On Dec 23, 2007 9:53 AM, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Sun, 23 Dec 2007, Carlos Corbacho wrote:
> >
> > Fix suspend-to-RAM on nForce 4 (CK804) boards by increasing
> > PCIBIOS_MIN_IO.
> >
> > Fixes kernel bugzilla #9528
> >
> > Problem:
> >
> > Linus' patch (52ade9b3b97fd3bea42842a056fe0786c28d0555) to re-order
> > suspend (and fix fall out from Rafael's earlier suspend reordering work)
> > broke suspend-to-RAM on nForce 4 (CK804) boards.
> >
> > Why:
> >
> > After debugging _PTS() in the DSDT, it turns out these nVidia boards are
> > trying to write to an IO port > 0x1000 (0x142E) during suspend. Before the
> > re-ordering, we got away with this.
>
> Very interesting.
>
> HOWEVER.
>
> I'd much rather figure out what the magic IO resource is that clashes.
>
> It's almost certainly some hidden and undocumented (or badly documented)
> ACPI IO area that the kernel doesn't know about, because it's not a
> regular PCI BAR resource, but some northbridge (or southbridge) magic
> register range.
>
> Those ranges *should* be reserved by the BIOS in the ACPI tables, but this
> would definitely not be the first time that doesn't happen.
>
> But the right fix would be for us to just figure out what the range is ass
> a PCI quirk, and just know to avoid it on purpose, ratehr than just being
> lucky and happen to avoid it because PCIBIOS_MIN_IO just happens to be
> bigger than the particular address.
>
> So can you:
>  - show what your /proc/ioports contains (*with* the bug triggering, ie
>non-working suspend, so we see what it is that actually ends up using
>that area)
>  - send out 'dmesg' for a boot (same deal)
>  - add "lspci -xxxvv" output to the deal too.
>
it looks like BIOS doesn't assign io port in bus 0. ( for PMU? or some 00:01.1)
and kernel try to assign value to it according to PCIBIOS_MIN_IO.

sometime some systems could have several HT chains.
bus: [00,08] on node 0 link 1
bus: 00 index 0 io port: [5000, dfff]
bus: 00 index 1 io port: [e000, efff]
bus: 00 index 2 io port: [0, fff]
bus: 00 index 3 mmio: [de00, dfff]
bus: 00 index 4 mmio: [e000, e7ff]
bus: 00 index 5 mmio: [a, b]
bus: 00 index 6 mmio: [f000, ]
bus: [80,86] on node 1 link 2
bus: 80 index 0 io port: [1000, 4fff]
bus: 80 index 1 io port: [f000, ]
bus: 80 index 2 mmio: [c000, ddff]
bus: 80 index 3 mmio: [e800, efff]

current all the buses will use ioport_resource

@@ -1158,6 +1162,8 @@ struct pci_bus * pci_create_bus(struct d
b->resource[0] = &ioport_resource;
b->resource[1] = &iomem_resource;

kernel could try to allocate resource from [0x1000, 0x4fff] for the
device in first HT chain...
..
I met one case: when some cards insert, i can not use mcp55 on die nic.
then i make one patch that could read KB northbridge pci conf space to
make different peer root bus has right io/iomem resource range.
pci_assign_resource could get right value for the devices that is not
assigned io value by BIOS.

YH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH - SH/Dreamcast] CD-Rom (GD-Rom) support for the SEGA Dreamcast

[Adrian McMenamin]

On 23/12/2007, Adrian McMenamin <[EMAIL PROTECTED]> wrote:
> This patch adds support for the CD-Rom (the so-called "GD-Rom") on the
> SEGA Dreamcast.
>
> The GD-Rom is based on the ATA-3 standard but implements a proprietary
> packet interface - the so-called Sega Packet Interface (SPI) and
> supports a proprietary CD format (the "Giga Disk"). This driver
> implements the SPI at least partially and will also read GD disks.
>
> There was a CD Rom driver for the 2.4 kernel series (out of mainline).
> This, though, is new code and unlike the previous driver uses DMA and
> not PIO to read disks.
>
> This is the third iteration of this patch - there remains the issue of
> __init versus __devinit - see http://lkml.org/lkml/2007/12/23/130 but
> I think otherwise it has dealt with most people's suggestions. The one
> exception is that Jens suggested using sector_div, though I found that
>  did not work.
>


Unfortunately that patch was lined wrapped.

Here it is (actually, slightly fixed) again.

Signed-off by: Adrian McMenamin <[EMAIL PROTECTED]>

-
diff -uprN linux-2.6-orig/drivers/block/Kconfig linux-2.6/drivers/block/Kconfig
--- linux-2.6-orig/drivers/block/Kconfig	2007-12-23 19:12:47.0 +
+++ linux-2.6/drivers/block/Kconfig	2007-12-23 20:13:54.0 +
@@ -105,6 +105,18 @@ config PARIDE
 	  "MicroSolutions backpack protocol", "DataStor Commuter protocol"
 	  etc.).
 
+config	GDROM
+	tristate "SEGA Dreamcast GD-ROM drive"
+	depends on SH_DREAMCAST
+	help
+	  A standard SEGA Dreamcast comes with a modified CD ROM drive called a
+	  "GD-ROM" by SEGA to signify it is capable of reading special disks
+	  with up to 1 GB of data. This drive will also read standard CD ROM
+	  disks. Select this option to access any disks in your GD ROM drive.
+	  Most users will want to say "Y" here.
+	  You can also build this as a module which will be called gdrom.ko
+
+
 source "drivers/block/paride/Kconfig"
 
 config BLK_CPQ_DA
diff -uprN linux-2.6-orig/drivers/cdrom/gdrom.c linux-2.6/drivers/cdrom/gdrom.c
--- linux-2.6-orig/drivers/cdrom/gdrom.c	1970-01-01 01:00:00.0 +0100
+++ linux-2.6/drivers/cdrom/gdrom.c	2007-12-23 20:13:54.0 +
@@ -0,0 +1,815 @@
+/* GD ROM driver for the SEGA Dreamcast
+ * copyright Adrian McMenamin, 2007
+ * With thanks to Marcus Comstedt and Nathan Keynes
+ * for work in reversing PIO and DMA
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define GDROM_DEV_NAME "gdrom"
+#define GD_SESSION_OFFSET 150
+
+/* GD Rom commands */
+#define GDROM_COM_SOFTRESET 0x08
+#define GDROM_COM_EXECDIAG 0x90
+#define GDROM_COM_PACKET 0xA0
+#define GDROM_COM_IDDEV 0xA1
+
+/* GD Rom registers */
+#define GDROM_BASE_REG 			0xA05F7000
+#define GDROM_ALTSTATUS_REG 		(GDROM_BASE_REG + 0x18)
+#define GDROM_DATA_REG 			(GDROM_BASE_REG + 0x80)
+#define GDROM_ERROR_REG 		(GDROM_BASE_REG + 0x84)
+#define GDROM_INTSEC_REG 		(GDROM_BASE_REG + 0x88)
+#define GDROM_SECNUM_REG 		(GDROM_BASE_REG + 0x8C)
+#define GDROM_BCL_REG  			(GDROM_BASE_REG + 0x90)
+#define GDROM_BCH_REG 			(GDROM_BASE_REG + 0x94)
+#define GDROM_DSEL_REG 			(GDROM_BASE_REG + 0x98)
+#define GDROM_STATUSCOMMAND_REG 	(GDROM_BASE_REG + 0x9C)
+#define GDROM_RESET_REG 		(GDROM_BASE_REG + 0x4E4)
+
+#define GDROM_DMA_STARTADDR_REG 	(GDROM_BASE_REG + 0x404)
+#define GDROM_DMA_LENGTH_REG 		(GDROM_BASE_REG + 0x408)
+#define GDROM_DMA_DIRECTION_REG 	(GDROM_BASE_REG + 0x40C)
+#define GDROM_DMA_ENABLE_REG 		(GDROM_BASE_REG + 0x414)
+#define GDROM_DMA_STATUS_REG 		(GDROM_BASE_REG + 0x418)
+#define GDROM_DMA_WAIT_REG 		(GDROM_BASE_REG + 0x4A0)
+#define GDROM_DMA_ACCESS_CTRL_REG 	(GDROM_BASE_REG + 0x4B8)
+ 
+#define GDROM_HARD_SECTOR 	2048
+#define BLOCK_LAYER_SECTOR 	512
+#define GD_TO_BLK 		4
+
+static struct platform_device *pd;
+static int gdrom_major;
+static wait_queue_head_t command_queue;
+static wait_queue_head_t request_queue;
+
+static DEFINE_SPINLOCK(gdrom_lock);
+static void gdrom_readdisk_dma(struct work_struct *work);
+static DECLARE_WORK(work, gdrom_readdisk_dma);
+static LIST_HEAD(gdrom_deferred);
+
+struct gdromt

Re: 2.6.24-rc6-mm1

[Andrew Morton]

On Sun, 23 Dec 2007 17:27:12 +0100 "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:

> On Dec 23, 2007 8:30 AM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc6/2.6.24-rc6-mm1/
> [snip]
> > +agk-dm-dm-snapshot-use-uninitialized_var.patch
> > +agk-dm-dm-raid1-handle-write-failures.patch
> > +agk-dm-dm-raid1-report-fault-status.patch
> > +agk-dm-dm-raid1-fix-eio-after-log-failure.patch
> > +agk-dm-dm-raid1-handle-read-failures.patch
> > +agk-dm-dm-raid1-mark-and-clear-nosync-writes.patch
> >
> >  device-mapper tree updates
> [snip]
> > +gregkh-driver-kref-add-kref_set.patch
> > +gregkh-driver-kobject-convert-sys-firmware-acpi-to-use-kobject_create.patch
> > +gregkh-driver-kobject-change-net-bridge-to-use-kobject_create_and_add.patch
> > +gregkh-driver-kobject-change-gfs2-to-use-kobject_init_and_add.patch
> > +gregkh-driver-kobject-change-drivers-infiniband-to-use-kobject_init_and_add.patch
> > +gregkh-driver-kobject-change-drivers-firmware-eddc-to-use-kobject_init_and_add.patch
> > +gregkh-driver-kobject-change-drivers-firmware-efivarsc-to-use-kobject_init_and_add.patch
> > +gregkh-driver-kobject-change-drivers-cpufreq-cpufreqc-to-use-kobject_init_and_add.patch
> > +gregkh-driver-kobject-change-drivers-edac-to-use-kobject_init_and_add.patch
> > +gregkh-driver-kobject-change-drivers-cpuidle-sysfsc-to-use-kobject_init_and_add.patch
> > +gregkh-driver-kobject-change-drivers-pci-hotplug-pci_hotplug_corec-to-use-kobject_init_and_add.patch
> > +gregkh-driver-kobject-change-drivers-base-sysc-to-use-kobject_init_and_add.patch
> > +gregkh-driver-kobject-change-arch-x86-kernel-cpu-intel_cacheinfoc-to-use-kobject_init_and_add.patch
> > +gregkh-driver-kobject-change-drivers-acpi-systemc-to-use-kobject_create_and_add.patch
> > +gregkh-driver-kobject-change-drivers-block-pktcdvdc-to-use-kobject_init_and_add.patch
> > +gregkh-driver-kobject-change-arch-sh-kernel-cpu-sh4-sqc-to-use-kobject_init_and_add.patch
> > +gregkh-driver-kobject-change-drivers-net-ibmvethc-to-use-kobject_init_and_add.patch
> > +gregkh-driver-kobject-change-drivers-parisc-pdc_stablec-to-use-kobject_init_and_add.patch
> > +gregkh-driver-kobject-change-arch-ia64-kernel-topologyc-to-use-kobject_init_and_add.patch
> > +gregkh-driver-kobject-change-drivers-md-mdc-to-use-kobject_init_and_add.patch
> > +gregkh-driver-kobject-change-arch-x86-kernel-cpu-mcheck-mce_amd_64c-to-use-kobject_create_and_add.patch
> > +gregkh-driver-kobject-change-arch-x86-kernel-cpu-mcheck-mce_amd_64c-to-use-kobject_init_and_add.patch
> > +gregkh-driver-kobject-the-cris-iop_fw_loadc-code-is-broken.patch
> > +gregkh-driver-kobject-convert-drivers-base-classc-to-use-kobject_init-add_ng.patch
> > +gregkh-driver-kobject-convert-drivers-base-corec-to-use-kobject_init-add_ng.patch
> > +gregkh-driver-kobject-convert-drivers-net-iseries_vethc-to-use-kobject_init-add_ng.patch
> > +gregkh-driver-kobject-convert-fs-char_devc-to-use-kobject_init-add_ng.patch
> > +gregkh-driver-kobject-convert-kernel-paramsc-to-use-kobject_init-add_ng.patch
> > +gregkh-driver-kobject-convert-kernel-userc-to-use-kobject_init-add_ng.patch
> > +gregkh-driver-kobject-convert-mm-slubc-to-use-kobject_init-add_ng.patch
> > +gregkh-driver-kobject-convert-net-bridge-br_ifc-to-use-kobject_init-add_ng.patch
> > +gregkh-driver-driver-add-driver_add_kobj-for-looney-iseries_veth-driver.patch
> > +gregkh-driver-kobject-change-drivers-base-bus-to-use-kobject_init_and_add.patch
> > +gregkh-driver-kobject-convert-block-elevatorc-to-use-kobject_init-add_ng.patch
> > +gregkh-driver-kobject-convert-block-ll_rw_blkc-to-use-kobject_init-add_ng.patch
> > +gregkh-driver-kobject-convert-drivers-md-mdc-to-use-kobject_init-add_ng.patch
> > +gregkh-driver-kobject-convert-kernel-modulec-to-use-kobject_init-add_ng.patch
> > +gregkh-driver-kobject-remove-kobject_add-as-no-one-uses-it-anymore.patch
> > +gregkh-driver-kobject-rename-kobject_add_ng-to-kobject_add.patch
> > +gregkh-driver-kobject-remove-kobject_init-as-no-one-uses-it-anymore.patch
> > +gregkh-driver-kobject-rename-kobject_init_ng-to-kobject_init.patch
> > +gregkh-driver-kobject-remove-kobject_register.patch
> > +gregkh-driver-kset-remove-kset_add-function.patch
> > +gregkh-driver-kobject-auto-cleanup-on-final-unref.patch
> > +gregkh-driver-kobject-convert-arch-from-kobject_unregister-to-kobject_put.patch
> > +gregkh-driver-kobject-convert-drivers-from-kobject_unregister-to-kobject_put.patch
> > +gregkh-driver-kobject-convert-fs-from-kobject_unregister-to-kobject_put.patch
> > +gregkh-driver-kobject-convert-remaining-kobject_unregister-to-kobject_put.patch
> > +gregkh-driver-kobject-remove-kobject_unregister-as-no-one-uses-it-anymore.patch
> > +gregkh-driver-driver-core-change-sysdev-classes-to-use-dynamic-kobject-names.patch
> > +gregkh-driver-kobject-remove-old-outdated-documentation.patch
> > +gregkh-driver-kobject-update-the-kobject-kset-documentation.patch
> > +gregkh-driver-kobject-add-sample-code-for-how-to-u

vfs_rmdir "bug"?

[Erez Zadok]

Al, Christoph,

vfs_rmdir is called from do_rmdir and does essentially this:

dentry_unhash(dentry);
error = dir->i_op->rmdir(dir, dentry);
if (!error)
d_delete(dentry);
dput(dentry);


do_rmdir grabs a ref on the dentry to be rmdir'ed, and also dput's it (so
it's nice and symmetric).  But vfs_rmdir seems asymmetric esp. when ->rmdir
returns and error (e.g., -ENOTEMPTY):

1. on error, the dentry will remain unhashed: shouldn't it be re-hashed (the
   way vfs_rename_dir does)?

2. vfs_rmdir unconditionally dput's the dentry, but it never grabbed that
   ref in the first place.  Is this really necessary.  We had a good dentry
   in the dcache before the call to rmdir(2), but after this unconditional
   dput(), it'll be removed from the dcache.  This would cause the vfs to
   have to re-issue a lookup on it next time someone tries to do anything
   with that directory.

I discovered this while trying to figure out why an expected-to-fail rmdir
on unionfs (one of the ltp tests tests for -ENOTEMPTY) left a lower inode
behind until umount(2) was called.  I fixed it by implementing
unionfs_d_iput, but still, it seems odd that we'll have dropped/unhashed a
possibly good dentry b/c ->rmdir failed.

Thanks,
Erez.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] fat: Editions to support fat_fallocate()

[Grant Likely]

On 12/23/07, OGAWA Hirofumi <[EMAIL PROTECTED]> wrote:
> "Grant Likely" <[EMAIL PROTECTED]> writes:
> >
> > However, digging further, when FALLOC_FL_KEEP_SIZE is set, I don't
> > think fat_cont_expand() has the behaviour that we want to implement.
> > When that flag is set, I think we simply want to add clusters
> > associated with the file to the FAT.  We don't want to clear them or
> > map them into the page cache yet (that should be done when the
> > filesize is increased for real).
> >
> > I believe a call to fat_allocate_clusters() is all that is needed in
> > this case.  Hirofumi, please correct me if I'm wrong.
>
> Right. And we need to care the limitation on FAT specification 
> (compatibility).

I not sure I fully understand what you mean.  Can you please
elaborate?  Are you referring to whether on not it will break other
FAT implementations if a file has more clusters allocated than it
needs?  If so, how do we decide whether or not it is acceptable?

Thanks,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Fwd: Re: [PATCH 0/5]PCI: x86 MMCONFIG]

[Loic Prylli]

On 12/20/2007 1:16 PM, Matthew Wilcox wrote:
> Oh, that's the same bug others (including me) have been complaining
> about.
>
> http://marc.info/?l=linux-kernel&m=118809338631160&w=2
>
>   
>> It hangs in exactly the same place every time.
>>
>> I am surmising that the write to that BAR is causing a MCE.
>> 
>
> Bad deduction.  What's happening is that the write to the BAR is causing
> it to overlap the decode for mmconfig space.  So the mmconfig write to
> set the BAR back never gets through.
>
> I have a different idea to fix this problem.  Instead of writing
> 0x, we could look for an unused bit of space in the E820 map and
> write, say, 0xdfff to the low 32-bits of a BAR.  Then it wouldn't
> overlap, and we could find its size using MMCONFIG.
>
> Does anyone know how Windows handles these machines? 



I just realized one thing: the bar sizing code in pci_read_bases() (that
writes 0x in the bars) does not seem to disable the
PCI_COMMAND_MEM/PCI_COMMAND_IO bits in the cmd register before
manipulating the BARs. And it seems nobody else ensures they are
disabled at this point either (or am I missing something?).


Touching the bars while they are enabled would be buggy behaviour from
our part, and something trivial to fix. And it might well fix that
particular problem (it's fair play from the machine to crash if we
create a decoding conflict, simply disabling the cmd bits in
pci_read_bases() should remove that conflict).

FWIW, to partially answer your last question, Windows does disable
mem-space and/or IO-space when sizing the bars of a device (I have some
traces of configuration-space-access taken on a window machine for one
of the PCI busses).



Loic






--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Updated Kernel Hacker's guide to git

[Stefan Richter]

Dieter Ries wrote:
> Robert P. J. Day schrieb:
>> when i got started with git, what i really wanted
>> was a list of what i (as a simple, non-developer user) could do once i
>> cloned a repository.
>>
>> to that end, i put together my own little reference list of git
>> commands.  for example, i collected ways to examine my repository --
>> git commands like branch, tag, log/shortlog, what-changed, show, grep,
>> blame, that sort of thing.  exactly the kind of stuff a new user might
>> want to know about, even without the ability to change anything.
> 
> Could you perhaps publish your reference list as kind of a christmas
> gift to all basic users like me?

Here are three out of four things which I do frequently with git repos:
I look at

  - commits and blobs in other people's trees with gitweb,

  - commits in a local tree with gitk,

  - specific changes to source code with qgit, using it as "git blame"
GUI.

(The fourth thing is feeding a driver subsystem git tree at kernel.org
using a minimum number of git commands.  Everything else which I do with
git I do so infrequently that I have to reread manuals all the time.)
-- 
Stefan Richter
-=-=-=== ==-- =-===
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: More verizon problems

[Matti Aarnio]

On Sun, Dec 23, 2007 at 02:30:50PM -0500, Gene Heskett wrote:
> Date: Sun, 23 Dec 2007 14:30:50 -0500
> From: Gene Heskett <[EMAIL PROTECTED]>
> Subject: More verizon problems
> To: linux-kernel@vger.kernel.org
> Content-type: text/plain; charset=iso-8859-1
> 
> Resend, with more odd data from fetchmail.log appended.

Looking at that log..

 
> PS:  From my fetchmail.log since I turned on the -v -v options an hour ago:
> --
> fetchmail: 6.3.6 querying pop.gmail.com (protocol POP3) at Sun 23 Dec 2007 
> 02:20:56 PM EST: poll started
> fetchmail: Trying to connect to 209.85.133.109/995...connected.
> fetchmail: Issuer Organization: Equifax
> fetchmail: Unknown Issuer CommonName
> fetchmail: Server CommonName: pop.gmail.com
> fetchmail: pop.gmail.com key fingerprint: 
> 44:A8:E9:2C:FB:A9:7E:6D:F9:DB:F3:62:B2:9E:F1:A9

This looks like correct and genuine gmail service.

> fetchmail: POP3< +OK Gpop ready for requests from 72.65.67.83 
> b11pf2510187ana.0
> fetchmail: POP3> CAPA
> fetchmail: POP3< +OK Capability list follows
> fetchmail: POP3< USER
> fetchmail: POP3< RESP-CODES
> fetchmail: POP3< EXPIRE 0
> fetchmail: POP3< LOGIN-DELAY 300
> fetchmail: POP3< X-GOOGLE-VERHOEVEN
> fetchmail: POP3< UIDL
> fetchmail: POP3< .
> fetchmail: POP3> USER gene.heskett
> fetchmail: POP3< +OK send PASS
> fetchmail: POP3> PASS *
> fetchmail: POP3< +OK Welcome.
> fetchmail: selecting or re-polling default folder
> fetchmail: POP3> STAT
> fetchmail: POP3< +OK 0 0
> fetchmail: No mail for gene.heskett at pop.gmail.com
> fetchmail: POP3> QUIT
> fetchmail: POP3< +OK Farewell.
> fetchmail: 6.3.6 querying pop.gmail.com (protocol POP3) at Sun 23 Dec 2007 
> 02:20:57 PM EST: poll completed
> fetchmail: not swapping UID lists, no UIDs seen this query
> fetchmail: Query status=1 (NOMAIL)
> ---
> 
> about 30 of those, there is never any mail for me at gmail.
> 
> Has my subscription info gotten contaminated somehow?

re-forward at gmail to verizon ?

> sorry for the noise folks, but this is a classic case of me and road rage.

I try to avoid that.  Gives others an illusion of me being smarter
than I am in reality...  :-)

> -- 
> Cheers, Gene

/Matti Aarnio
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.24-rc6-mm1

[Sam Ravnborg]

On Sun, Dec 23, 2007 at 02:53:34PM +0100, Rafael J. Wysocki wrote:
> On Sunday, 23 of December 2007, Rafael J. Wysocki wrote:
> > On Sunday, 23 of December 2007, Ingo Molnar wrote:
> > > 
> > > * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> > > 
> > > > Well it doesn't build on x86-64 for me:
> > > > 
> > > >   CHK include/linux/compile.h
> > > >   CC  arch/x86/ia32/../../../fs/compat_binfmt_elf.o
> > > > Assembler messages:
> > > > Fatal error: can't create 
> > > > arch/x86/ia32/../../../fs/.tmp_compat_binfmt_elf.o: No such file or 
> > > > directory
> > > > make[2]: *** [arch/x86/ia32/../../../fs/compat_binfmt_elf.o] Error 2
> > > > 
> > > > I will post the .config if anyone is interested.
> > > 
> > > yes, please send the .config.
> > 
> > Attached.
> > 
> > It also may be relevant that I compile the kernel with "make O=../build".
> 
> I ran the compilation once again and it worked.  Strange.
Try to delete your fs/ directory in your output dir.
Then I expect the same bug to surface again.

I guess it is because arch/x86/ia32/ is built before fs/ and
gcc cannot create directories for the output files and
it is the dependency files that triggers the error as this
is the first file to be generated.
The right fix is to move the build of compat_binfmt_elf to
fs/Makefile as already discussed.

Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Boot time module loading problem

[Johannes Berg]

> What could be causing such a problem?

I would guess that user has "ssb" loaded from his initrd for some reason
and upgraded the modules by hand.

johannes


signature.asc
Description: This is a digitally signed message part

[PATCH] uml: user of helper_wait() got missed when it got extra arguments

[Al Viro]

Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
 arch/um/drivers/harddog_user.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/um/drivers/harddog_user.c b/arch/um/drivers/harddog_user.c
index b56f8e0..448ba59 100644
--- a/arch/um/drivers/harddog_user.c
+++ b/arch/um/drivers/harddog_user.c
@@ -79,14 +79,14 @@ int start_watchdog(int *in_fd_ret, int *out_fd_ret, char 
*sock)
n = read(in_fds[0], &c, sizeof(c));
if (n == 0) {
printk("harddog_open - EOF on watchdog pipe\n");
-   helper_wait(pid);
+   helper_wait(pid, 1, NULL);
err = -EIO;
goto out_close_out;
}
else if (n < 0) {
printk("harddog_open - read of watchdog pipe failed, "
   "err = %d\n", errno);
-   helper_wait(pid);
+   helper_wait(pid, 1, NULL);
err = n;
goto out_close_out;
}
-- 
1.5.3.GIT

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Morer verizon problems

[Matti Aarnio]

On Sun, Dec 23, 2007 at 02:10:39PM -0500, Gene Heskett wrote:
> Date: Sun, 23 Dec 2007 14:10:39 -0500
> From: Gene Heskett <[EMAIL PROTECTED]>
> Subject: Morer verizon problems
> To: linux-kernel@vger.kernel.org
> 
> Just for a heads up, for about the last 8 hours, verizon, my ISP, has been
> inserting themselves into the path between my gmail account and my local
> fetchmail of this email subcription at pop.gmail.com.

Gene,

The Received: header data are telling something else.
You read them from bottom-most up -- new one is always inserted on top of
the existing headers.

   Received: by nz-out-0506.google.com with SMTP id x7so90741nzc.3 for
 <[EMAIL PROTECTED]>; Thu, 20 Dec 2007 18:08:08 -0800 (PST)

It does look like you have a forwarding setting at gmail to your
verizononline.net service.  If you had chosen to pull email out of
gmail, then perhaps you would not have had any verizon problems.

While conspiracy mongering has its fun, I do think that you are in fact
causing this all to yourself by trying to push the message flood to
Verizon..  For what it matters - LKML has 3 subscribers on  @verizon.net
addresses.

I do run my own mail-server, and my Linux mailboxes are at present over
1 GB/y.  Gmail mailbox would be a bit larger - underlying database
granularity is around 128 or 256 kB, as I recall having read about
google technology.


> Worse yet they are bouncing the messages in a way that makes it look as if I
> sent them when they in fact originated at vger.kernel.org.  Somehow they have 
> convinced themselves that any mailing list this busy must be spam and is to 
> be 
> bounced.  Either that or they, verizon, since they sleep with M$, have taken 
> a 
> large under the table payment to screw with linux in any way they can.  It 
> bears investigating.
> 
> I called just now and screamed bloody murder at tech support, and in about 15 
> minutes I started getting the list again, BUT they are still in the path 
> between vger and my fetchmail daemon as shown below.

Yes, I would fetch directly from gmail, if I were you...

/Matti Aarnio   --   one of   

> Or at least that is how I am interpreting the incoming headers, which now 
> look 
> like this by the time they hit my inbox but with my SA headers clipped:
> ---
>  Received: from incoming.verizon.net [206.46.232.10]
> by coyote.coyote.den with POP3 (fetchmail-6.3.6)
> for <[EMAIL PROTECTED]> (single-drop); Thu, 20 Dec 2007 21:10:08 
> -0500 (EST)
>  Received: from mailbag1.bizmailsrvcs.net ([172.18.12.131])
>   by vms051.mailsrvcs.net
>   (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
>   with ESMTP id <[EMAIL PROTECTED]> for
>   [EMAIL PROTECTED]; Thu, 20 Dec 2007 20:08:11 -0600 (CST)
>  Received: from [64.233.162.238] (port= helo=nz-out-0506.google.com)
>   by mailbag1.bizmailsrvcs.net with esmtp (Exim 4.68)
>   (envelope-from <[EMAIL PROTECTED]>)
>   id 1J5XG9-00052G-Dufor [EMAIL PROTECTED]; Thu,
>   20 Dec 2007 20:05:09 -0600
>  Received: by nz-out-0506.google.com with SMTP id x7so90741nzc.3 for
>   <[EMAIL PROTECTED]>; Thu, 20 Dec 2007 18:08:08 -0800 (PST)
>  Received: by 10.142.132.2 with SMTP id f2mr436687wfd.221.1198202887677; Thu,
>   20 Dec 2007 18:08:07 -0800 (PST)
>  Received: by 10.142.222.3 with SMTP id u3cs177296wfg; Thu,
>   20 Dec 2007 18:08:07 -0800 (PST)
>  Received: by 10.100.202.9 with SMTP id z9mr1420295anf.42.1198202883749; Thu,
>   20 Dec 2007 18:08:03 -0800 (PST)
>  Received: from vger.kernel.org (vger.kernel.org [209.132.176.167])
>   by mx.google.com with ESMTP id q26si917844ele.6.2007.12.20.18.07.38; Thu,
>   20 Dec 2007 18:08:03 -0800 (PST)
>  Received: ([EMAIL PROTECTED]) by vger.kernel.org via listexpand   id
>   S1759056AbXLUCHP (ORCPT  + 49 others); Thu,
>   20 Dec 2007 21:07:15 -0500
>  Received: ([EMAIL PROTECTED]) by vger.kernel.org id S1754373AbXLUB7V
>   (ORCPT ); Thu, 20 Dec 2007 20:59:21 -0500
>  Received: from smtp.polymtl.ca
>   ([132.207.4.11]:53375 "EHLO smtp.polymtl.ca"   rhost-flags-OK-OK-OK-OK)
>   by vger.kernel.org with ESMTP  id S1761264AbXLUB7M
>   (ORCPT ); Thu, 20 Dec 2007 20:59:12 
> -0500
>  Received: from dijkstra.casi.polymtl.ca
>   (dijkstra.casi.polymtl.ca [132.207.72.10]) by smtp.polymtl.ca 
> (8.13.8/8.13.8)
>   with ESMTP id lBL1vVHB024689
>   (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu,
>   20 Dec 2007 20:57:32 -0500
>  Received: from compudj by dijkstra.casi.polymtl.ca with local (Exim 4.63)
>   (envelope-from <[EMAIL PROTECTED]>) id 1J5X8g-00040X-Gt; Thu,
>   20 Dec 2007 20:57:26 -0500
>  Date: Thu, 20 Dec 2007 20:54:50 -0500
>  From: Mathieu Desnoyers <[EMAIL PROTECTED]>
>  Subject: [patch 12/24] Immediate Values - Architecture Independent Code
>  X-Originating-IP: [172.18.12.131]
>  Sender: [EMAIL PROTECTED]
>  To: [EMAIL PROTECTED],
>  Ingo Molnar <[EMAIL PROTECTED]>,
>  linux-kernel@vger.kernel.org
>  Cc: Mathieu Desnoyers <[EMAIL PROTECTED]>,
>  Rusty Russell <[EMAIL PROTECTED]

[PATCH - SH/Dreamcast] CD-Rom (GD-Rom) support for the SEGA Dreamcast

[Adrian McMenamin]

This patch adds support for the CD-Rom (the so-called "GD-Rom") on the
SEGA Dreamcast.

The GD-Rom is based on the ATA-3 standard but implements a proprietary
packet interface - the so-called Sega Packet Interface (SPI) and
supports a proprietary CD format (the "Giga Disk"). This driver
implements the SPI at least partially and will also read GD disks.

There was a CD Rom driver for the 2.4 kernel series (out of mainline).
This, though, is new code and unlike the previous driver uses DMA and
not PIO to read disks.

This is the third iteration of this patch - there remains the issue of
__init versus __devinit - see http://lkml.org/lkml/2007/12/23/130 but
I think otherwise it has dealt with most people's suggestions. The one
exception is that Jens suggested using sector_div, though I found that
 did not work.

Signed-off by: Adrian McMenamin <[EMAIL PROTECTED]>

diff -ruN linux-2.6-orig/drivers/block/Kconfig linux-2.6/drivers/block/Kconfig
--- linux-2.6-orig/drivers/block/Kconfig2007-12-23 19:12:47.0 
+
+++ linux-2.6/drivers/block/Kconfig 2007-12-23 19:08:20.0 +
@@ -105,6 +105,18 @@
  "MicroSolutions backpack protocol", "DataStor Commuter protocol"
  etc.).

+config GDROM
+   tristate "SEGA Dreamcast GD-ROM drive"
+   depends on SH_DREAMCAST
+   help
+ A standard SEGA Dreamcast comes with a modified CD ROM drive called a
+ "GD-ROM" by SEGA to signify it is capable of reading special disks
+ with up to 1 GB of data. This drive will also read standard CD ROM
+ disks. Select this option to access any disks in your GD ROM drive.
+ Most users will want to say "Y" here.
+ You can also build this as a module which will be called gdrom.ko
+
+
diff -ruN linux-2.6-orig/drivers/cdrom/gdrom.c linux-2.6/drivers/cdrom/gdrom.c
--- linux-2.6-orig/drivers/cdrom/gdrom.c1970-01-01 01:00:00.0 
+0100
+++ linux-2.6/drivers/cdrom/gdrom.c 2007-12-23 19:08:20.0 +
@@ -0,0 +1,815 @@
+/* GD ROM driver for the SEGA Dreamcast
+ * copyright Adrian McMenamin, 2007
+ * With thanks to Marcus Comstedt and Nathan Keynes
+ * for work in reversing PIO and DMA
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define GDROM_DEV_NAME "gdrom"
+#define GD_SESSION_OFFSET 150
+
+/* GD Rom commands */
+#define GDROM_COM_SOFTRESET 0x08
+#define GDROM_COM_EXECDIAG 0x90
+#define GDROM_COM_PACKET 0xA0
+#define GDROM_COM_IDDEV 0xA1
+
+/* GD Rom registers */
+#define GDROM_BASE_REG 0xA05F7000
+#define GDROM_ALTSTATUS_REG(GDROM_BASE_REG + 0x18)
+#define GDROM_DATA_REG (GDROM_BASE_REG + 0x80)
+#define GDROM_ERROR_REG(GDROM_BASE_REG + 0x84)
+#define GDROM_INTSEC_REG   (GDROM_BASE_REG + 0x88)
+#define GDROM_SECNUM_REG   (GDROM_BASE_REG + 0x8C)
+#define GDROM_BCL_REG  (GDROM_BASE_REG + 0x90)
+#define GDROM_BCH_REG  (GDROM_BASE_REG + 0x94)
+#define GDROM_DSEL_REG (GDROM_BASE_REG + 0x98)
+#define GDROM_STATUSCOMMAND_REG(GDROM_BASE_REG + 0x9C)
+#define GDROM_RESET_REG(GDROM_BASE_REG + 0x4E4)
+
+#define GDROM_DMA_STARTADDR_REG(GDROM_BASE_REG + 0x404)
+#define GDROM_DMA_LENGTH_REG   (GDROM_BASE_REG + 0x408)
+#define GDROM_DMA_DIRECTION_REG(GDROM_BASE_REG + 0x40C)
+#define GDROM_DMA_ENABLE_REG   (GDROM_BASE_REG + 0x414)
+#define GDROM_DMA_STATUS_REG   (GDROM_BASE_REG + 0x418)
+#define GDROM_DMA_WAIT_REG (GDROM_BASE_REG + 0x4A0)
+#define GDROM_DMA_ACCESS_CTRL_REG  (GDROM_BASE_REG + 0x4B8)
+
+#define GDROM_HARD_SECTOR  2048
+#define BLOCK_LAYER_SECTOR 512
+#define GD_TO_BLK  4
+
+static struct platform_device *pd;
+static int gdrom_major;
+static wait_queue_head_t command_queue;
+static wait_queue_head_t request_queue;
+
+static DEFINE_SPINLOCK(gdrom_lock);
+static void gdrom_readdisk_dma(struct work_struct *work);
+static DECLARE_WORK(work, gdrom_readdisk_dma)

Boot time module loading problem

[Larry Finger]

With 2.6.24-rc5, a b43 user reports a problem at bootup. The b43 module, which 
should be loaded by
the ssb module, fails with the following type of message:

ssb: Sonics Silicon Backplane found on PCI device :0c:00.0
b43: disagrees about version of symbol ssb_device_is_enabled
b43: Unknown symbol ssb_device_is_enabled
b43: disagrees about version of symbol ssb_pcicore_dev_irqvecs_enable
b43: Unknown symbol ssb_pcicore_dev_irqvecs_enable
b43: disagrees about version of symbol ssb_bus_may_powerdown
b43: Unknown symbol ssb_bus_may_powerdown

< and more similar lines>

If the user issues the commands

rmmod ssb; modprobe b43

then the modules are loaded correctly and the wireless device works.

What could be causing such a problem?

Larry

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

xfs|loop|raid: attempt to access beyond end of device

[Janos Haar]

Hello, list,

I have a little problem on one of my productive system.

The system sometimes crashed, like this:

Dec 23 08:53:05 Albohacen-global kernel: attempt to access beyond end of
device
Dec 23 08:53:05 Albohacen-global kernel: loop0: rw=1, want=50552830649176,
limit=3085523200
Dec 23 08:53:05 Albohacen-global kernel: Buffer I/O error on device loop0,
logical block 6319103831146
Dec 23 08:53:05 Albohacen-global kernel: lost page write due to I/O error on
loop0
...
Dec 23 09:08:02 Albohacen-global kernel: attempt to access beyond end of
device
Dec 23 09:08:02 Albohacen-global kernel: loop0: rw=1, want=50552830649688,
limit=3085523200
Dec 23 09:08:02 Albohacen-global kernel: Buffer I/O error on device loop0,
logical block 6319103831210
Dec 23 09:08:02 Albohacen-global kernel: lost page write due to I/O error on
loop0
...
Dec 23 09:08:07 Albohacen-global kernel: attempt to access beyond end of
device
Dec 23 09:08:07 Albohacen-global kernel: loop0: rw=1, want=50552830657824,
limit=3085523200
Dec 23 09:08:07 Albohacen-global kernel: BUG: soft lockup detected on CPU#0!
Dec 23 09:08:07 Albohacen-global kernel:
Dec 23 09:08:07 Albohacen-global kernel: Call Trace:
Dec 23 09:08:07 Albohacen-global kernel:[]
_spin_lock+0x9/0xb
Dec 23 09:08:07 Albohacen-global kernel:  []
softlockup_tick+0xd5/0xea
Dec 23 09:08:07 Albohacen-global kernel:  []
run_local_timers+0x13/0x15
Dec 23 09:08:07 Albohacen-global kernel:  []
update_process_times+0x4c/0x78
Dec 23 09:08:07 Albohacen-global kernel:  []
smp_local_timer_interrupt+0x34/0x54
Dec 23 09:08:07 Albohacen-global kernel:  []
smp_apic_timer_interrupt+0x43/0x5a
Dec 23 09:08:07 Albohacen-global kernel:  []
apic_timer_interrupt+0x66/0x70
Dec 23 09:08:07 Albohacen-global kernel:[]
__mutex_lock_slowpath+0x20f/0x225
Dec 23 09:08:07 Albohacen-global kernel:  []
mutex_lock+0x25/0x29
Dec 23 09:08:07 Albohacen-global kernel:  []
xfs_icsb_modify_counters+0x121/0x1c2
Dec 23 09:08:07 Albohacen-global kernel:  []
xfs_mod_incore_sb+0x34/0x75
Dec 23 09:08:07 Albohacen-global kernel:  []
xfs_bmap_add_extent_delay_real+0xe33/0xefa
Dec 23 09:08:07 Albohacen-global kernel:  []
xfs_alloc_vextent+0x35f/0x3e2
Dec 23 09:08:07 Albohacen-global kernel:  []
xfs_bmap_add_extent+0x20b/0x386
Dec 23 09:08:07 Albohacen-global kernel:  []
xfs_btree_init_cursor+0x34/0x1c6
Dec 23 09:08:07 Albohacen-global kernel:  []
xfs_bmapi+0x947/0xf44
Dec 23 09:08:07 Albohacen-global kernel:  []
xfs_iext_get_ext+0x34/0x58
Dec 23 09:08:07 Albohacen-global kernel:  []
xfs_iomap_write_allocate+0x239/0x3bf
Dec 23 09:08:07 Albohacen-global kernel:  []
xfs_iomap+0x2b1/0x355
Dec 23 09:08:07 Albohacen-global kernel:  []
mempool_alloc_slab+0x11/0x13
Dec 23 09:08:07 Albohacen-global kernel:  []
xfs_bmap+0x10/0x12
Dec 23 09:08:07 Albohacen-global kernel:  []
xfs_map_blocks+0x32/0x68
Dec 23 09:08:07 Albohacen-global kernel:  []
xfs_page_state_convert+0x31a/0x636
Dec 23 09:08:07 Albohacen-global kernel:  []
xfs_vm_writepage+0xa5/0xde
Dec 23 09:08:07 Albohacen-global kernel:  []
generic_writepages+0x1c8/0x334
Dec 23 09:08:07 Albohacen-global kernel:  []
xfs_vm_writepage+0x0/0xde
Dec 23 09:08:07 Albohacen-global kernel:  []
xfs_vm_writepages+0x44/0x4d
Dec 23 09:08:07 Albohacen-global kernel:  []
do_writepages+0x2b/0x3a
Dec 23 09:08:07 Albohacen-global kernel:  []
__writeback_single_inode+0x1d1/0x35f
Dec 23 09:08:07 Albohacen-global kernel:  []
sync_sb_inodes+0x1ac/0x269
Dec 23 09:08:07 Albohacen-global kernel:  []
keventd_create_kthread+0x0/0x79
Dec 23 09:08:07 Albohacen-global kernel:  []
writeback_inodes+0x99/0xf6
Dec 23 09:08:07 Albohacen-global kernel:  []
pdflush+0x0/0x1f9
Dec 23 09:08:07 Albohacen-global kernel:  []
wb_kupdate+0x9f/0x112
Dec 23 09:08:08 Albohacen-global kernel:  []
pdflush+0x0/0x1f9
Dec 23 09:08:08 Albohacen-global kernel:  []
pdflush+0x14b/0x1f9
Dec 23 09:08:08 Albohacen-global kernel:  []
__wake_up_common+0x3e/0x68
Dec 23 09:08:08 Albohacen-global kernel:  []
wb_kupdate+0x0/0x112
Dec 23 09:08:08 Albohacen-global kernel:  []
kthread+0xf5/0x128
Dec 23 09:08:08 Albohacen-global kernel:  []
schedule_tail+0x45/0xae
Dec 23 09:08:08 Albohacen-global kernel:  []
child_rip+0xa/0x12
Dec 23 09:08:08 Albohacen-global kernel:  []
keventd_create_kthread+0x0/0x79
Dec 23 09:08:08 Albohacen-global kernel:  []
kthread+0x0/0x128
Dec 23 09:08:08 Albohacen-global kernel:  []
child_rip+0x0/0x12
Dec 23 09:08:08 Albohacen-global kernel:
Dec 23 09:08:08 Albohacen-global kernel: BUG: soft lockup detected on CPU#0!
Dec 23 09:08:08 Albohacen-global kernel:
Dec 23 09:08:08 Albohacen-global kernel: Call Trace:
Dec 23 09:08:08 Albohacen-global kernel:[]
_spin_lock+0x9/0xb
Dec 23 09:08:08 Albohacen-global kernel:  []
softlockup_tick+0xd5/0xea
Dec 23 09:08:08 Albohacen-global kernel:  []
run_local_timers+0x13/0x15
Dec 23 09:08:08 Albohacen-global kernel:  []
update_process_times+0x4c/0x78
Dec 23 09:08:08 Albohacen-global kernel:  []
smp_local_timer_interrupt+0x34/0x54
Dec 23 09:08:08 Albohacen-global kernel:  []
smp_apic_timer_in

Re: [Bug 9528] x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM

[Linus Torvalds]

On Sun, 23 Dec 2007, Ingo Molnar wrote:
> 
> This script will probe all unused ports as per /proc/ioports and will 
> list "suspect" IO port areas: ones that do not produce the expected 0xff 
> default reply from unclaimed IO ports. Magic chipset register areas can 
> potentially be mapped this way.

This probably won't work, if the APCI ports aren't reserved.

The way suspend-to-ram works is that there's a magic port that the CPU 
reads from, which just basically turns the CPU off. 

Same goes for C-states, and while we should recover from that gracefully 
(ie the CPU comes back at wakeup events), if you don't do the right setup, 
that can also just hang the machine..

So this script sounds rather dangerous for this case (while it probably 
tends to work fine for the case of the ACPI ports being properly reserved: 
*most* IO devices tend to try to avoid having too many side effects on 
normal reads - the most common one tends to be to reset any pending 
interrupts from a device, but that one won't matter if we don't have a 
driver listening to that device).

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

More verizon problems

[Gene Heskett]

Resend, with more odd data from fetchmail.log appended.

Just for a heads up, for about the last 8 hours, verizon, my ISP, has been 
inserting themselves into the path between my gmail account and my local 
fetchmail of this email subcription at pop.gmail.com.

Worse yet they are bouncing the messages in a way that makes it look as if I
sent them when they in fact originated at vger.kernel.org.  Somehow they have 
convinced themselves that any mailing list this busy must be spam and is to be 
bounced.  Either that or they, verizon, since they sleep with M$, have taken a 
large under the table payment to screw with linux in any way they can.  It 
bears investigating.

I called just now and screamed bloody murder at tech support, and in about 15 
minutes I started getting the list again, BUT they are still in the path 
between vger and my fetchmail daemon as shown below.

Or at least that is how I am interpreting the incoming headers, which now look 
like this by the time they hit my inbox but with my SA headers clipped:
---
Received: from incoming.verizon.net [206.46.232.10]
by coyote.coyote.den with POP3 (fetchmail-6.3.6)
for <[EMAIL PROTECTED]> (single-drop); Thu, 20 Dec 2007 21:10:08 -0500 
(EST)
 Received: from mailbag1.bizmailsrvcs.net ([172.18.12.131])
 by vms051.mailsrvcs.net
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 with ESMTP id <[EMAIL PROTECTED]> for
 [EMAIL PROTECTED]; Thu, 20 Dec 2007 20:08:11 -0600 (CST)
 Received: from [64.233.162.238] (port= helo=nz-out-0506.google.com)
 by mailbag1.bizmailsrvcs.net with esmtp (Exim 4.68)
 (envelope-from <[EMAIL PROTECTED]>)
 id 1J5XG9-00052G-Dufor [EMAIL PROTECTED]; Thu,
 20 Dec 2007 20:05:09 -0600
 Received: by nz-out-0506.google.com with SMTP id x7so90741nzc.3 for
 <[EMAIL PROTECTED]>; Thu, 20 Dec 2007 18:08:08 -0800 (PST)
 Received: by 10.142.132.2 with SMTP id f2mr436687wfd.221.1198202887677; Thu,
 20 Dec 2007 18:08:07 -0800 (PST)
 Received: by 10.142.222.3 with SMTP id u3cs177296wfg; Thu,
 20 Dec 2007 18:08:07 -0800 (PST)
 Received: by 10.100.202.9 with SMTP id z9mr1420295anf.42.1198202883749; Thu,
 20 Dec 2007 18:08:03 -0800 (PST)
 Received: from vger.kernel.org (vger.kernel.org [209.132.176.167])
 by mx.google.com with ESMTP id q26si917844ele.6.2007.12.20.18.07.38; Thu,
 20 Dec 2007 18:08:03 -0800 (PST)
 Received: ([EMAIL PROTECTED]) by vger.kernel.org via listexpand   id
 S1759056AbXLUCHP (ORCPT  + 49 others); Thu,
 20 Dec 2007 21:07:15 -0500
 Received: ([EMAIL PROTECTED]) by vger.kernel.org id S1754373AbXLUB7V
 (ORCPT ); Thu, 20 Dec 2007 20:59:21 -0500
 Received: from smtp.polymtl.ca
 ([132.207.4.11]:53375 "EHLO smtp.polymtl.ca"   rhost-flags-OK-OK-OK-OK)
 by vger.kernel.org with ESMTP  id S1761264AbXLUB7M
 (ORCPT ); Thu, 20 Dec 2007 
20:59:12 -0500
 Received: from dijkstra.casi.polymtl.ca
 (dijkstra.casi.polymtl.ca [132.207.72.10]) by smtp.polymtl.ca 
(8.13.8/8.13.8)
 with ESMTP id lBL1vVHB024689
 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu,
 20 Dec 2007 20:57:32 -0500
 Received: from compudj by dijkstra.casi.polymtl.ca with local (Exim 4.63)
 (envelope-from <[EMAIL PROTECTED]>) id 1J5X8g-00040X-Gt; Thu,
 20 Dec 2007 20:57:26 -0500
 Date: Thu, 20 Dec 2007 20:54:50 -0500
 From: Mathieu Desnoyers <[EMAIL PROTECTED]>
 Subject: [patch 12/24] Immediate Values - Architecture Independent Code
 X-Originating-IP: [172.18.12.131]
 Sender: [EMAIL PROTECTED]
 To: [EMAIL PROTECTED],
 Ingo Molnar <[EMAIL PROTECTED]>,
 linux-kernel@vger.kernel.org
 Cc: Mathieu Desnoyers <[EMAIL PROTECTED]>,
 Rusty Russell <[EMAIL PROTECTED]>
 Message-id: <[EMAIL PROTECTED]>
 X-Forwarded-for: [EMAIL PROTECTED] [EMAIL PROTECTED]
 Content-disposition: inline;
 filename=immediate-values-architecture-independent-code.patch
 Precedence: bulk
 Delivered-to: [EMAIL PROTECTED]
 Received-SPF: pass (google.com: best guess record for domain of
 [EMAIL PROTECTED] designates 209.132.176.167 as permitted
 sender) client-ip=209.132.176.167;
 Authentication-Results: mx.google.com; spf=pass (google.com: best guess 
record
 for domain of [EMAIL PROTECTED] designates 209.132.176.167 
as
 permitted sender) [EMAIL PROTECTED]
 X-Forwarded-To: [EMAIL PROTECTED]
 X-Poly-FromMTA: (dijkstra.casi.polymtl.ca [132.207.72.10]) at Fri,
 21 Dec 2007 01:57:31 +
 References: <[EMAIL PROTECTED]>
 X-Mailing-List: linux-kernel@vger.kernel.org
 List-Id: 
 User-Agent: quilt/0.46-1
 X-procmail: user=gene
 Status: RO
 X-Status: UC
 X-KMail-EncryptionState: 
 X-KMail-SignatureState: 
 X-KMail-MDN-Sent: 

Any mail experts here want to debunk my findings, jump right in, I'm not an
email guru, but it sure looks to me as if they are rerouting ANY port 25
access through their servers now.  And M$ would pay millions to screw us,
and has, its a matter of record.

PS:  From my fetchmail.log since I turned on the -v -v options an hour ago:
--
fetchmail: 6.3.6 querying pop.gmail.com (protocol POP3) at Sun 23 Dec 2007 
02:20

Re: [Bug 9528] x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM

[Ingo Molnar]

* Linus Torvalds <[EMAIL PROTECTED]> wrote:

> > Why:
> > 
> > After debugging _PTS() in the DSDT, it turns out these nVidia boards are
> > trying to write to an IO port > 0x1000 (0x142E) during suspend. Before the
> > re-ordering, we got away with this.
> 
> Very interesting.
> 
> HOWEVER.
> 
> I'd much rather figure out what the magic IO resource is that clashes.

Carlos, could you please run the following script as root:

  http://redhat.com/~mingo/misc/probe-ports.sh

and send us the resulting probe-ports.txt file?

This script will probe all unused ports as per /proc/ioports and will 
list "suspect" IO port areas: ones that do not produce the expected 0xff 
default reply from unclaimed IO ports. Magic chipset register areas can 
potentially be mapped this way.

[ CAREFUL: This probes IO ports which might in theory trigger various
  nastiness such as lockups. I this on a few boxes and the script
  worked, but save any work in case you get lockups. ]

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2.6] remove Documentation/mips/GT64120.README

[Dmitri Vorobiev]

Being related to 2.4 kernel, the information presented in the 
`Documentation/mips/GT64120.README' file is outdated. Worse, the document 
contents are plain misleading nowadays because the text mentions files and 
directories, which have been deleted, moved or restructured for 2.6.

In my opinion, this file should be deleted from the 2.6 kernel tree.

Signed-off-by: Dmitri Vorobiev <[EMAIL PROTECTED]>

--

diff --git a/Documentation/mips/00-INDEX b/Documentation/mips/00-INDEX
index 3f13bf8..8ae9cff 100644
--- a/Documentation/mips/00-INDEX
+++ b/Documentation/mips/00-INDEX
@@ -2,5 +2,3 @@
- this file.
 AU1xxx_IDE.README
- README for MIPS AU1XXX IDE driver.
-GT64120.README
-   - README for dir with info on MIPS boards using GT-64120 or GT-64120A.
diff --git a/Documentation/mips/GT64120.README 
b/Documentation/mips/GT64120.README
deleted file mode 100644
index 2d0eec9..000
--- a/Documentation/mips/GT64120.README
+++ /dev/null
@@ -1,65 +0,0 @@
-README for arch/mips/gt64120 directory and subdirectories
-
-Jun Sun, [EMAIL PROTECTED] or [EMAIL PROTECTED]
-01/27, 2001
-
-MOTIVATION
---
-
-Many MIPS boards share the same system controller (or CPU companian chip),
-such as GT-64120.  It is highly desirable to let these boards share
-the same controller code instead of duplicating them.
-
-This directory is meant to hold all MIPS boards that use GT-64120 or GT-64120A.
-
-
-HOW TO ADD A BOARD
---
- 
-. Create a subdirectory include/asm/gt64120/.  
-
-. Create a file called gt64120_dep.h under that directory.
-
-. Modify include/asm/gt64120/gt64120.h file to include the new gt64120_dep.h
-  based on config options.  The board-dep section is at the end of 
-  include/asm/gt64120/gt64120.h file. There you can find all required
-  definitions include/asm/gt64120//gt64120_dep.h file must supply.
-
-. Create a subdirectory arch/mips/gt64120/ directory to hold
-  board specific routines.
-
-. The GT-64120 common code is supplied under arch/mips/gt64120/common 
directory.
-  It includes:
-   1) arch/mips/gt64120/pci.c -
-   common PCI routine, include the top-level pcibios_init()
-   2) arch/mips/gt64120/irq.c -
-   common IRQ routine, include the top-level do_IRQ() 
-  [This part really belongs to arch/mips/kernel. jsun]
-   3) arch/mips/gt64120/gt_irq.c -
-   common IRQ routines for GT-64120 chip.  Currently it only 
handles
-   the timer interrupt.
-
-. Board-specific routines are supplied under arch/mips/gt64120/ dir.
-   1) arch/mips/gt64120//pci.c - it provides bus fixup routine
-   2) arch/mips/gt64120//irq.c - it provides enable/disable irqs
-   and board irq setup routine (irq_setup)
-   3) arch/mips/gt64120//int-handler.S -
-   The first-level interrupt dispatching routine.
-   4) a bunch of other "normal" stuff (setup, prom, dbg_io, reset, etc)
-
-. Follow other "normal" procedure to modify configuration files, etc.
-
-
-TO-DO LIST
---
-
-. Expand arch/mips/gt64120/gt_irq.c to handle all GT-64120 interrupts.
-  We probably need to introduce GT_IRQ_BASE  in board-dep header file,
-  which is used the starting irq_nr for all GT irqs.
-
-  A function, gt64120_handle_irq(), will be added so that the first-level
-  irq dispatcher will call this function if it detects an interrupt
-  from GT-64120.
-
-. More support for GT-64120 PCI features (2nd PCI bus, perhaps)
-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Morer verizon problems

[Gene Heskett]

Just for a heads up, for about the last 8 hours, verizon, my ISP, has been 
inserting themselves into the path between my gmail account and my local 
fetchmail of this email subcription at pop.gmail.com.

Worse yet they are bouncing the messages in a way that makes it look as if I
sent them when they in fact originated at vger.kernel.org.  Somehow they have 
convinced themselves that any mailing list this busy must be spam and is to be 
bounced.  Either that or they, verizon, since they sleep with M$, have taken a 
large under the table payment to screw with linux in any way they can.  It 
bears investigating.

I called just now and screamed bloody murder at tech support, and in about 15 
minutes I started getting the list again, BUT they are still in the path 
between vger and my fetchmail daemon as shown below.

Or at least that is how I am interpreting the incoming headers, which now look 
like this by the time they hit my inbox but with my SA headers clipped:
---
Received: from incoming.verizon.net [206.46.232.10]
by coyote.coyote.den with POP3 (fetchmail-6.3.6)
for <[EMAIL PROTECTED]> (single-drop); Thu, 20 Dec 2007 21:10:08 -0500 
(EST)
 Received: from mailbag1.bizmailsrvcs.net ([172.18.12.131])
 by vms051.mailsrvcs.net
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 with ESMTP id <[EMAIL PROTECTED]> for
 [EMAIL PROTECTED]; Thu, 20 Dec 2007 20:08:11 -0600 (CST)
 Received: from [64.233.162.238] (port= helo=nz-out-0506.google.com)
 by mailbag1.bizmailsrvcs.net with esmtp (Exim 4.68)
 (envelope-from <[EMAIL PROTECTED]>)
 id 1J5XG9-00052G-Dufor [EMAIL PROTECTED]; Thu,
 20 Dec 2007 20:05:09 -0600
 Received: by nz-out-0506.google.com with SMTP id x7so90741nzc.3 for
 <[EMAIL PROTECTED]>; Thu, 20 Dec 2007 18:08:08 -0800 (PST)
 Received: by 10.142.132.2 with SMTP id f2mr436687wfd.221.1198202887677; Thu,
 20 Dec 2007 18:08:07 -0800 (PST)
 Received: by 10.142.222.3 with SMTP id u3cs177296wfg; Thu,
 20 Dec 2007 18:08:07 -0800 (PST)
 Received: by 10.100.202.9 with SMTP id z9mr1420295anf.42.1198202883749; Thu,
 20 Dec 2007 18:08:03 -0800 (PST)
 Received: from vger.kernel.org (vger.kernel.org [209.132.176.167])
 by mx.google.com with ESMTP id q26si917844ele.6.2007.12.20.18.07.38; Thu,
 20 Dec 2007 18:08:03 -0800 (PST)
 Received: ([EMAIL PROTECTED]) by vger.kernel.org via listexpand   id
 S1759056AbXLUCHP (ORCPT  + 49 others); Thu,
 20 Dec 2007 21:07:15 -0500
 Received: ([EMAIL PROTECTED]) by vger.kernel.org id S1754373AbXLUB7V
 (ORCPT ); Thu, 20 Dec 2007 20:59:21 -0500
 Received: from smtp.polymtl.ca
 ([132.207.4.11]:53375 "EHLO smtp.polymtl.ca"   rhost-flags-OK-OK-OK-OK)
 by vger.kernel.org with ESMTP  id S1761264AbXLUB7M
 (ORCPT ); Thu, 20 Dec 2007 20:59:12 -0500
 Received: from dijkstra.casi.polymtl.ca
 (dijkstra.casi.polymtl.ca [132.207.72.10]) by smtp.polymtl.ca 
(8.13.8/8.13.8)
 with ESMTP id lBL1vVHB024689
 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu,
 20 Dec 2007 20:57:32 -0500
 Received: from compudj by dijkstra.casi.polymtl.ca with local (Exim 4.63)
 (envelope-from <[EMAIL PROTECTED]>) id 1J5X8g-00040X-Gt; Thu,
 20 Dec 2007 20:57:26 -0500
 Date: Thu, 20 Dec 2007 20:54:50 -0500
 From: Mathieu Desnoyers <[EMAIL PROTECTED]>
 Subject: [patch 12/24] Immediate Values - Architecture Independent Code
 X-Originating-IP: [172.18.12.131]
 Sender: [EMAIL PROTECTED]
 To: [EMAIL PROTECTED],
 Ingo Molnar <[EMAIL PROTECTED]>,
 linux-kernel@vger.kernel.org
 Cc: Mathieu Desnoyers <[EMAIL PROTECTED]>,
 Rusty Russell <[EMAIL PROTECTED]>
 Message-id: <[EMAIL PROTECTED]>
 X-Forwarded-for: [EMAIL PROTECTED] [EMAIL PROTECTED]
 Content-disposition: inline;
 filename=immediate-values-architecture-independent-code.patch
 Precedence: bulk
 Delivered-to: [EMAIL PROTECTED]
 Received-SPF: pass (google.com: best guess record for domain of
 [EMAIL PROTECTED] designates 209.132.176.167 as permitted
 sender) client-ip=209.132.176.167;
 Authentication-Results: mx.google.com; spf=pass (google.com: best guess record
 for domain of [EMAIL PROTECTED] designates 209.132.176.167 as
 permitted sender) [EMAIL PROTECTED]
 X-Forwarded-To: [EMAIL PROTECTED]
 X-Poly-FromMTA: (dijkstra.casi.polymtl.ca [132.207.72.10]) at Fri,
 21 Dec 2007 01:57:31 +
 References: <[EMAIL PROTECTED]>
 X-Mailing-List: linux-kernel@vger.kernel.org
 List-Id: 
 User-Agent: quilt/0.46-1
 X-procmail: user=gene
 Status: RO
 X-Status: UC
 X-KMail-EncryptionState: 
 X-KMail-SignatureState: 
 X-KMail-MDN-Sent: 

Any mail experts here want to debunk my findings, jump right in, I'm not an
email guru, but it sure looks to me as if they are rerouting ANY port 25
access through their servers now.  And M$ would pay millions to screw us,
and has, its a matter of record.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Lo!  Men have become the tool of their tools.
-- Henry David

[PATCH] i2c: adds support for i2c bus on Frescale CPM1/CPM2 controllers

[Jochen Friedrich]

Using the port of 2.4 code from Vitaly Bordug <[EMAIL PROTECTED]>
and the actual algorithm used by the i2c driver of the DBox code on
cvs.tuxboc.org from Tmbinc, Gillem ([EMAIL PROTECTED]). Renamed i2c-rpx.c and
i2c-algo-8xx.c to i2c-cpm.c and converted the driver to an
of_platform_driver.

Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8272ads.dts |   10 +
arch/powerpc/boot/dts/mpc866ads.dts  |   10 +
arch/powerpc/boot/dts/mpc885ads.dts  |   10 +
arch/powerpc/platforms/8xx/mpc885ads_setup.c |5 +
drivers/i2c/busses/Kconfig   |   10 +
drivers/i2c/busses/Makefile  |1 +
drivers/i2c/busses/i2c-cpm.c |  757 ++
7 files changed, 803 insertions(+), 0 deletions(-)
create mode 100644 drivers/i2c/busses/i2c-cpm.c

diff --git a/arch/powerpc/boot/dts/mpc8272ads.dts 
b/arch/powerpc/boot/dts/mpc8272ads.dts
index 7285ca1..7273996 100644
--- a/arch/powerpc/boot/dts/mpc8272ads.dts
+++ b/arch/powerpc/boot/dts/mpc8272ads.dts
@@ -215,6 +215,16 @@
linux,network-index = <1>;
fsl,cpm-command = <16200300>;
};
+
+   [EMAIL PROTECTED] {
+   compatible = "fsl,mpc8248-i2c",
+"fsl,cpm2-i2c",
+"fsl,cpm-i2c";
+   reg = <11860 20 8afc 2>;
+   interrupts = <1 8>;
+   interrupt-parent = <&PIC>;
+   fsl,cpm-command = <2960>;
+   };
};

PIC: [EMAIL PROTECTED] {
diff --git a/arch/powerpc/boot/dts/mpc866ads.dts 
b/arch/powerpc/boot/dts/mpc866ads.dts
index 90f2293..c79cac1 100644
--- a/arch/powerpc/boot/dts/mpc866ads.dts
+++ b/arch/powerpc/boot/dts/mpc866ads.dts
@@ -141,6 +141,16 @@
interrupts = <1e 3>;
interrupt-parent = <&Cpm_pic>;
};
+
+   [EMAIL PROTECTED] {
+   compatible = "fsl,mpc866-i2c",
+"fsl,cpm1-i2c",
+"fsl,cpm-i2c";
+   reg = <860 20 3c80 30>;
+   interrupts = <10 3>;
+   interrupt-parent = <&Cpm_pic>;
+   fsl,cpm-command = <0010>;
+   };
};
};
};
diff --git a/arch/powerpc/boot/dts/mpc885ads.dts 
b/arch/powerpc/boot/dts/mpc885ads.dts
index 8848e63..fd9c9d7 100644
--- a/arch/powerpc/boot/dts/mpc885ads.dts
+++ b/arch/powerpc/boot/dts/mpc885ads.dts
@@ -213,6 +213,16 @@
fsl,cpm-command = <0080>;
linux,network-index = <2>;
};
+
+   [EMAIL PROTECTED] {
+   compatible = "fsl,mpc885-i2c",
+"fsl,cpm1-i2c",
+"fsl,cpm-i2c";
+   reg = <860 20 3c80 30>;
+   interrupts = <10>;
+   interrupt-parent = <&CPM_PIC>;
+   fsl,cpm-command = <0010>;
+   };
};
};

diff --git a/arch/powerpc/platforms/8xx/mpc885ads_setup.c 
b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
index 2cf1b6a..4377521 100644
--- a/arch/powerpc/platforms/8xx/mpc885ads_setup.c
+++ b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
@@ -157,6 +157,11 @@ static struct cpm_pin mpc885ads_pins[] = {
{CPM_PORTE, 28, CPM_PIN_OUTPUT},
{CPM_PORTE, 29, CPM_PIN_OUTPUT},
#endif
+   /* I2C */
+#ifdef CONFIG_I2C_8XX
+   {CPM_PORTB, 26, CPM_PIN_INPUT | CPM_PIN_OPENDRAIN},
+   {CPM_PORTB, 27, CPM_PIN_INPUT | CPM_PIN_OPENDRAIN},
+#endif
};

static void __init init_ioports(void)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index c466c6c..5950172 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -114,6 +114,16 @@ config I2C_BLACKFIN_TWI_CLK_KHZ
help
  The unit of the TWI clock is kHz.

+config I2C_CPM
+   tristate "Freescale CPM1 or CPM2 (MPC8xx/826x)"
+   depends on (CPM1 || CPM2) && I2C && PPC_OF
+   help
+ This supports the use of the I2C interface on Freescale
+ processors with CPM1 or CPM2.
+
+ This driver can also be built as a module.  If so, the module
+ will be called i2c-cpm.
+
config I2C_DAVINCI
tristate "DaVinci I2C driver"
depends on ARCH_DAVINCI
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 81d43c2..a39 100644
--- a/drivers/i2c/busses/Makefile

[PATCH] MAINTAINERS: update Corey Thomas email address

[Joe Perches]

> On Sat, 2007-12-22 at 11:48 -0800, Joe Perches wrote:
> > Your entry in MAINTAINERS is no longer valid.
> > Should that be fixed or deleted from MAINTAINERS?

On Sat, 2007-12-22 at 18:08 -0500, Corey Thomas wrote:
> This email, [EMAIL PROTECTED] is good.  ISP change.

Signed-off-by: Joe Perches <[EMAIL PROTECTED]>

diff --git a/MAINTAINERS b/MAINTAINERS
index 3c7db62..da22333 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3147,7 +3147,7 @@ S:Maintained
 
 RAYLINK/WEBGEAR 802.11 WIRELESS LAN DRIVER
 P: Corey Thomas
-M: [EMAIL PROTECTED]
+M: [EMAIL PROTECTED]
 L: [EMAIL PROTECTED]
 S: Maintained
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

OOPS: 2.6.23.11 in PadLock-AES when used in LRW-Mode

[Alexander Eichhorn]

Hi,

while playing around with AES encrypted block devices (in LRW mode)  
on top of Software Raid-1/5 volumes I experienced a set of Kernel  
OOPSes which seem to be related to the current PadLock-AES driver.  
PadLock-AES in LRW mode also failed when layered directly above a raw  
disk partition (without Raid). The same set of tests using software  
AES including the i586 optimized AES implementation worked. PadLock- 
AES in CBC mode did also work without problems.


Unfortunately the OOPSes were triggered randomly, but most often  
during the first 30 seconds of a test or even during filesystem  
creation. When turning Highmem off, the bug is triggered less often.  
Increasing the chunk size of a Raid-5 array from 64k to 1M and  
fitting cryptsetup's alignment (--align-payload=2048) and ext3's  
block size and stride (-b 4096 -E stride=256) seemed to have solved  
the problem entirely at a first glance (some tests performed without  
errors), but later I experienced the same OOPSes again.


(Please CC me because I'm not subscribed to LKML.)

Regards,
Alexander

Below is a typical configuration where the OOPSes occured:

Configuration
-
Kernel: 2.6.23.11 (.config appended)
CPU: Via C7 (VIA EN-15000 board)
Mem: 1GB, but Highmem support turned off
Crypt-Mode: aes-lrw-benbi
Key-Size: 384 bit

Hardware and Block-Layer Setup
--
Disks: 3x WD5000ABYS-01TNA0 500GB SATA (on Silicon Image SiI 3114  
Controller)

Partitions: 2 per disk (20GB, 480GB)
no Raid: just using plain /dev/sda1
Raid-1: on first partition over all three disks
Raid-5: on second partition over all three disks
Crypto: LUKS, mode: aes-lrw-benbi, hash: SHA256, key-size 384 bit
FS: ext3

Hardware and Block-Layer Setup
--

# Create RAID, crypted block device, and filesystem
#
mdadm --create /dev/md0 --raid-devices=3 --level=1 /dev/sda1 /dev/ 
sdb1 /dev/sdc1
echo "myPassPhrase" | cryptsetup --verbose --batch-mode -d - -c aes- 
lrw-benbi:sha256 -s 384 luksFormat /dev/md0

echo "myPassPhrase" | cryptsetup luksOpen /dev/md0 testfs
mkfs.ext3 /dev/mapper/testfs

# mount and run bonnie (replace  with an existing user name,  
not 'root')

#
mount /dev/mapper/testfs /mnt
mkdir /mnt/bonnie
chmod 777 /mnt/bonnie/
bonnie -d /mnt/bonnie/ -s 2G:4k -n 0 -m plain -u 

# run a second bonnie or dd to generate I/O pressure
#
bonnie -d /mnt/bonnie/ -s 2G:4k -n 0 -m plain -u 
dd if=/dev/mapper/testfs of=/dev/null bs=1M


Kernel OOPSes
-

Below are the two kinds of OOPSes I experienced during my tests.

OOPS #1 - in aes_encrypt
 
===

BUG: unable to handle kernel paging request at virtual address f800
 printing eip:
c03bbc8c
*pde = 
Oops:  [#1]
PREEMPT
Modules linked in:
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010282   (2.6.23.11-vanilla #1)
EIP is at aes_encrypt+0x17/0x1f
eax: f4679400   ebx: f4679450   ecx: 0001   edx: f4679420
esi: f7f0   edi: f7f0   ebp: f7557e40   esp: f7557de4
ds: 007b   es: 007b   fs:   gs:   ss: 0068
Process kcryptd/0 (pid: 593, ti=f7556000 task=f7cbca80 task.ti=f7556000)
Stack: f7557e10 eb4a3ff0 f7f0 c0283f56  00611b00 f3c9e020  
f7557eb4
   0010 0010 f7557e90 498d985c b414002d a9e6eb46  
49eb773b f4679400
   c03bbc75 f3c9e020 f3c9e000 c05b91a4 f7557ecc c0284101  
c03bbc75 c1569460

Call Trace:
 [] crypt+0x1a0/0x1fa
 [] aes_encrypt+0x0/0x1f
 [] encrypt+0x32/0x37
 [] aes_encrypt+0x0/0x1f
 [] crypt_convert_scatterlist+0x73/0xc3
 [] crypt_convert+0xc7/0xff
 [] kcryptd_do_work+0x28a/0x305
 [] kcryptd_do_work+0x0/0x305
 [] run_workqueue+0x8c/0x128
 [] worker_thread+0x0/0xbe
 [] worker_thread+0xb2/0xbe
 [] autoremove_wake_function+0x0/0x35
 [] kthread+0x36/0x5c
 [] kthread+0x0/0x5c
 [] kernel_thread_helper+0x7/0x10
 ===
Code: 89 c2 8b 44 24 1c 85 c0 75 cc 83 c4 3c 89 d0 5b 5e 5f 5d c3 57  
89 d7 56 89 ce 8d 50
 2f 53 83 e2 f0 9c 9d b9 01 00 00 00 8d 5a 30  0f a7 c8 5b 5e 5f  
c3 57 83 c0 2f 56 89 d7 53 89 ce 83 e0 f0

EIP: [] aes_encrypt+0x17/0x1f SS:ESP 0068:f7557de4
note: kcryptd/0[593] exited with preempt_count 2
 
===



OOPS #2 - in aes_encrypt
 
===

BUG: unable to handle kernel paging request at virtual address f800
 printing eip:
c03bbc8c
*pde = 
Oops:  [#1]
PREEMPT
Modules linked in:
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010282   (2.6.23.11-vanilla #1)
EIP is at aes_encrypt+0x17/0x1f
eax: f4aad000   ebx: f4aad050   ecx: 0001   edx: f4aad020
esi: f7f0   edi: f7f0   ebp: f7557e40   esp: f7557de4
ds: 007b   es: 007b   fs:   gs:   ss: 0068
Process kcryptd/0 (pid: 593, ti=f7556000 task=f7ccea80 task.ti=f7556000)
Stack: f7557e10 cf45eff0 f7f0 c0283f56  001f990e f4ae2020  
f7557eb4
   

Re: [PATCH] Fix RTC_AIE with CONFIG_HPET_EMULATE_RTC

[Clemens Ladisch]

Bernhard Walle wrote:
> In the current code, RTC_AIE doesn't work if the RTC relies on
> CONFIG_HPET_EMULATE_RTC because the code sets the RTC_AIE flag
> in hpet_set_rtc_irq_bit(). The interrupt handles does accidentally
> check for RTC_PIE and not RTC_AIE when comparing the time
> which was set in hpet_set_alarm_time().
> 
> This patch is against 2.6.24-rc5-mm1.
> 
> 
> Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]>

Acked-by: Clemens Ladisch <[EMAIL PROTECTED]>

> ---
>  arch/x86/kernel/hpet.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/arch/x86/kernel/hpet.c
> +++ b/arch/x86/kernel/hpet.c
> @@ -657,7 +657,7 @@ irqreturn_t hpet_rtc_interrupt(int irq, 
>   hpet_pie_count = 0;
>   }
>  
> - if (hpet_rtc_flags & RTC_PIE &&
> + if (hpet_rtc_flags & RTC_AIE &&
>   (curr_time.tm_sec == hpet_alarm_time.tm_sec) &&
>   (curr_time.tm_min == hpet_alarm_time.tm_min) &&
>   (curr_time.tm_hour == hpet_alarm_time.tm_hour))
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.24-rc5-mm 3/3] gpiolib: obsolete drivers/i2c/chips/pca9539.c

[David Brownell]

> From: eric miao <[EMAIL PROTECTED]>
> Date: Wed, 19 Dec 2007 16:40:04 +0800
> Subject: [PATCH] gpiolib: mark drivers/i2c/chips/pca9539.c as deprecated
> 
> use drivers/gpio/pca9539.c instead.
> 
> Signed-off-by: eric miao <[EMAIL PROTECTED]>
> Acked-by: Ben Gardner <[EMAIL PROTECTED]>
> Acked-by: Jean Delvare <[EMAIL PROTECTED]>
> ---
>  Documentation/i2c/chips/pca9539 |3 +++
>  drivers/i2c/chips/Kconfig   |7 +--
>  2 files changed, 8 insertions(+), 2 deletions(-)

Yeah, this version looks unlikely to break anyone's systems.


> @@ -75,6 +75,9 @@ config SENSORS_PCA9539
> This driver can also be built as a module.  If so, the module
> will be called pca9539.
> 
> +   This driver is deprecated and will be dropped soon. Use
> +   drivers/gpio/pca9539.c instead.
> +
>  config SENSORS_PCF8591
>   tristate "Philips PCF8591"
>   depends on EXPERIMENTAL
>

I suggest defining a date, such as "will be removed in the 2.6.26
kernel", and adding it to Documentation/feature-removal-schedule.txt ...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [MIPS] MEM_SDREFCFG is not defined for Alchemy DB1550 (compile fail)

[Alon Bar-Lev]

Hello,

Forgot to write that I checked mips & linus gits, and the problem still exists.

Best Regards,
Alon Bar-Lev.

On 12/23/07, Alon Bar-Lev <[EMAIL PROTECTED]> wrote:
> Hello,
>
> When I have:
> CONFIG_MIPS_DB1550
> CONFIG_SOC_AU1550
> CONFIG_SOC_AU1X00
> CONFIG_PM
>
> MEM_SDREFCFG is used at:
> arch/mips/au1000/common/power.c::pm_do_freq()
>
> While the MEM_SDREFCFG constant is declare only for CONFIG_SOC_AU1000,
> CONFIG_SOC_AU1500, CONFIG_SOC_AU1100 at:
> include/asm-mips/mach-au1x00/au1000.h
>
> Maybe MEM_SDREFCFG should be defined for CONFIG_SOC_AU1X00?
> Or there should be #ifdef for its usage in power.c?
>
> Best Regards,
> Alon Bar-Lev.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kvm-devel] [PATCH 27/50] KVM: Support assigning userspace memory to the guest

[Avi Kivity]

Avi Kivity wrote:

From: Izik Eidus <[EMAIL PROTECTED]>

Instead of having the kernel allocate memory to the guest, let userspace
allocate it and pass the address to the kernel.

This is required for s390 support, but also enables features like memory
sharing and using hugetlbfs backed memory.

  


[...]


@@ -728,11 +752,27 @@ static int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
 
 		memset(new.phys_mem, 0, npages * sizeof(struct page *));

memset(new.rmap, 0, npages * sizeof(*new.rmap));
-   for (i = 0; i < npages; ++i) {
-   new.phys_mem[i] = alloc_page(GFP_HIGHUSER
-| __GFP_ZERO);
-   if (!new.phys_mem[i])
+   if (user_alloc) {
+   unsigned long pages_num;
+
+   new.user_alloc = 1;
+   down_read(¤t->mm->mmap_sem);
+
+   pages_num = get_user_pages(current, current->mm,
+  mem->userspace_addr,
+  npages, 1, 0, new.phys_mem,
+  NULL);
+
  


I just combined a patch that changes the 'force' parameter to 
get_user_pages from 0 to 1, into this patch, to avoid introducing a bug 
and its fix in the same patchset.  I won't be resending this patch since 
the change is too trivial.  Same change applies to patch 48, "KVM: MMU: 
Partial swapping of guest memory".


--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Bug 9528] x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM

[Linus Torvalds]

On Sun, 23 Dec 2007, Linus Torvalds wrote:
> 
> For an example of what I mean, see the file "drivers/pci/quirks.c", and 
> check out the quirks for various chipsets:

Side note - we already do have some quirks for the CK804 chipset, we 
probably just don't have enough (ie we have it for some HT stuff, but 
there are probably different ranges for ACPI etc other registers). 

I'm adding Brice Goglin to the Cc, since he was the one that created those 
quirks, which implies that he probably has access to documentation on that 
thing.

Brice: see the unfolding sad story on

http://bugzilla.kernel.org/show_bug.cgi?id=9528

which doesn't include Carlos' previous email, but does include my reply, 
so you can see what the resource allocation issue is..

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM

[Linus Torvalds]

On Sun, 23 Dec 2007, Rafael J. Wysocki wrote:
> 
> The patch is fine by me, so if anyone has objections, please speak up.

There is absolutely *no* way I will apply this in an -rc6 release.

The number of machines this will break is totally unknown. It might be 
zero. It might be hundreds.  We just don't know. We might hit another 
unlucky allocation that we just happened to avoid before.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM

[Ingo Molnar]

* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:

> > 0x1500 has been picked here as a nice, round and more conservative 
> > value than 0x4000, and which covers 0x142E.
> 
> The patch is fine by me, so if anyone has objections, please speak up.

i'm quite nervous about that approach, partly due to the "black magic" 
interaction of commit 2ba84684e8c. Could we try to figure out what's 
really going on here, instead of playing with a general limit (which 
might break other boxes)?

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Bug 9528] x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM

[Linus Torvalds]

On Sun, 23 Dec 2007, Carlos Corbacho wrote:
>
> Fix suspend-to-RAM on nForce 4 (CK804) boards by increasing
> PCIBIOS_MIN_IO.
> 
> Fixes kernel bugzilla #9528
> 
> Problem:
> 
> Linus' patch (52ade9b3b97fd3bea42842a056fe0786c28d0555) to re-order
> suspend (and fix fall out from Rafael's earlier suspend reordering work)
> broke suspend-to-RAM on nForce 4 (CK804) boards.
> 
> Why:
> 
> After debugging _PTS() in the DSDT, it turns out these nVidia boards are
> trying to write to an IO port > 0x1000 (0x142E) during suspend. Before the
> re-ordering, we got away with this.

Very interesting.

HOWEVER.

I'd much rather figure out what the magic IO resource is that clashes. 

It's almost certainly some hidden and undocumented (or badly documented) 
ACPI IO area that the kernel doesn't know about, because it's not a 
regular PCI BAR resource, but some northbridge (or southbridge) magic 
register range.

Those ranges *should* be reserved by the BIOS in the ACPI tables, but this 
would definitely not be the first time that doesn't happen.

But the right fix would be for us to just figure out what the range is ass 
a PCI quirk, and just know to avoid it on purpose, ratehr than just being 
lucky and happen to avoid it because PCIBIOS_MIN_IO just happens to be 
bigger than the particular address.

So can you:
 - show what your /proc/ioports contains (*with* the bug triggering, ie 
   non-working suspend, so we see what it is that actually ends up using 
   that area)
 - send out 'dmesg' for a boot (same deal)
 - add "lspci -xxxvv" output to the deal too.

and also make them part of the bugzilla history (I'm cc'ing bugzilla here, 
and added the bug number to the subject, so hopefully this thread ends up 
being archived there too).

> There was some previous work in the PCIBIOS_MIN_IO area over two years ago
> (71db63acff69618b3d9d3114bd061938150e146b) which bumped this to 0x4000,
> but this was reverted (2ba84684e8cf6f980e4e95a2300f53a505eb794e) after
> causing new and entirely different problems on another nForce board.

The problem here is classic: these magic ranges tend to be *different* on 
different boards (because they don't tend to be fixed by hardware, they 
are programmed regions set up by firmware), so trying to change 
PCIBIOS_MIN_IO to avoid a problem on one board is almost certain to just 
introduce it on another board instead.

On *your* particular board, 0x142E is used for something, but on somebody 
elses board it might be 0x162E, and now changing PCIBIOS_MIN_IO to 0x1500 
might make that other board hang instead.

So you seem to have debugged this very successfully, and I'm wondering if 
you might be able to find out where that 0x142e comes from, and we could 
fix it for *all* boards using that chipset by just figuring out what the 
*hardware* rules (rather than the random firmware setup that will be 
different on different boards) for that chipset actually are!

For an example of what I mean, see the file "drivers/pci/quirks.c", and 
check out the quirks for various chipsets:

 - quirk_ali7101_acpi()

   Knows about the magic ALI ACPI and SMB OI regions

 - quirk_piix4_acpi(), quirk_ich6_lpc_acpi(), quirk_ich4_lpc_acpi()

   Same thing for the Intel chipsets

 - quirk_vt82c586_acpi(), quirk_vt82c686_acpi()

   VIA chipsets

etc etc.

It would be *wonderful* if somebody could figure out what the equivalent 
quirks for nVidia chipsets are! Because otherwise we'll just end up 
bouncing back and forth between different random IO allocations, and they 
are all almost guaranteed to cause the same problems, just on different 
boards!

It's sometimes possible to even just guess what the registers are, even if 
things are undocumented. In particular, that 142E range is almost 
certainly programmed into the host bridge or possibly a "LPC controller" 
or similar, and it will probably show up as the bytes "20 14" in the 
output from lspci, so we can guess which register it is that sets the 
base. That's not *always* how it works, but it's sometimes possible to 
guess (although you usually need to see a few different cases of the same 
chipset to have any kind of confirmation of the guess).

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Peculiar out-of-sync boot log lines

[Nick Warne]

On Sun, 2 Dec 2007 19:30:34 +0100
Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:

Hi Bart,

Top posting! g.

This patch works fine on my system with this peculiar DVD drive, and
log reports are perfect.

Updated to Linus' git today - 2.6.24-rc6-g5b825ed2

/var/log/messages:

Dec 23 09:36:04 linuxamd kernel: ide0: BM-DMA at 0xd000-0xd007, BIOS 
settings: hda:DMA, hdb:DMA
Dec 23 09:36:04 linuxamd kernel: ide1: BM-DMA at 0xd008-0xd00f, BIOS 
settings: hdc:DMA, hdd:DMA
Dec 23 09:36:04 linuxamd kernel: hda: UDMA/66 mode selected
Dec 23 09:36:04 linuxamd kernel: hdb: UDMA/66 mode selected
Dec 23 09:36:04 linuxamd kernel: hdc: UDMA/66 mode selected
Dec 23 09:36:04 linuxamd kernel: hdd: UDMA/66 mode selected
Dec 23 09:36:04 linuxamd kernel: hda: max request size: 128KiB
Dec 23 09:36:04 linuxamd kernel: hda: 160086528 sectors (81964 MB) w/2048KiB 
Cache, CHS=65535/16/63
Dec 23 09:36:04 linuxamd kernel: hda: cache flushes supported
Dec 23 09:36:04 linuxamd kernel:  hda: hda1 hda2 hda3 hda4
Dec 23 09:36:04 linuxamd kernel: hdb: max request size: 128KiB
Dec 23 09:36:04 linuxamd kernel: hdb: 30015216 sectors (15367 MB) w/2048KiB 
Cache, CHS=29777/16/63
Dec 23 09:36:04 linuxamd kernel: hdb: cache flushes not supported
Dec 23 09:36:04 linuxamd kernel:  hdb: hdb1
Dec 23 09:36:04 linuxamd kernel: hdc: max request size: 128KiB
Dec 23 09:36:04 linuxamd kernel: hdc: 39876480 sectors (20416 MB) w/2048KiB 
Cache, CHS=39560/16/63
Dec 23 09:36:04 linuxamd kernel: hdc: cache flushes not supported
Dec 23 09:36:04 linuxamd kernel:  hdc: hdc1
Dec 23 09:36:04 linuxamd kernel: hdd: ATAPI 48X DVD-ROM DVD-R-RAM
CD-R/RW drive, 2048kB Cache

and

/var/log/syslog

Dec 23 09:36:04 linuxamd kernel: hdb: Maxtor 51536H2, ATA DISK drive
Dec 23 09:36:04 linuxamd kernel: hda: Maxtor 6Y080L0, ATA DISK drive
Dec 23 09:36:04 linuxamd kernel: hdd: TSSTcorp CDDVDW SH-S202J, ATAPI 
CD/DVD-ROM drive
Dec 23 09:36:04 linuxamd kernel: hdc: Maxtor 52049H3, ATA DISK drive


> On Sunday 02 December 2007, Randy Dunlap wrote:
> > On Sat, 1 Dec 2007 22:59:35 +0100 Bartlomiej Zolnierkiewicz wrote:
> > 
> > > Thanks for reporting/debugging it guys!
> > > 
> > > > Something in there needs to insert a '\n' before the "skipping
> > > > word" message. Since it doesn't do that right now, the
> > > > KERN_DEBUG string appears as "<7>"
> > > 
> > > This seems like a good occasion to fix ide_dma_verbose() for good
> > > so... :)
> > > 
> > > [ patch is against current Linus tree so might not apply to
> > > 2.6.23.9 ]
> > > 
> > > [PATCH] ide: DMA reporting and validity checking fixes
> > > 
> > > * ide_xfer_verbose() fixups:
> > >   - beautify returned mode names
> > >   - fix PIO5 reporting
> > >   - make it return 'const char *'
> > > 
> > > * Change printk() level from KERN_DEBUG to KERN_INFO in
> > > ide_find_dma_mode().
> > > 
> > > * Add ide_id_dma_bug() helper based on ide_dma_verbose() to check
> > > for invalid DMA info in identify block.
> > > 
> > > * Use ide_id_dma_bug() in ide_tune_dma() and ide_driveid_update().
> > > 
> > >   As a result DMA won't be tuned or will be disabled after tuning
> > > if device reports inconsistent info about enabled DMA mode
> > > (ide_dma_verbose() does the same checks while the IDE device is
> > > probed by ide-{cd,disk} device driver).
> > > 
> > > * Since (id->capability & 1) && id->tDMA is a valid configuration
> > > handle it correctly in ide_id_dma_bug().
> > > 
> > > * Remove no longer needed ide_dma_verbose().
> > > 
> > > This patch should fix the following problem with out-of-sync IDE
> > > messages reported by Nick Warned:
> > > 
> > >hdd: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB
> > > Cache<7>hdd: skipping word 93 validity check
> > > , UDMA(66)
> > > 
> > > and later debugged by Mark Lord to be caused by:
> > > 
> > > ide_dma_verbose()
> > > printk( ... "2048kB Cache");
> > > eighty_ninty_three()
> > > printk(KERN_DEBUG "%s: skipping word 93 validity
> > > check\n"); ide_dma_verbose()
> > > printk(", UDMA(66)"
> > > 
> > > Please note that as a result ide-{cd,disk} device drivers won't
> > > report the DMA speed used but this is intended since now DMA mode
> > > being used is always reported by IDE core code.
> > > 
> > > Cc: Nick Warne <[EMAIL PROTECTED]>
> > > Cc: Mark Lord <[EMAIL PROTECTED]>
> > > Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>

~ skip

Nick
-- 
Free Software Foundation Associate Member 5508
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/