* [DNX#2006040142001507] [U-Boot-Users] i.MX support for scb9328 cleaned up [...]
From: DENX Support System @ 2006-04-01 1:20 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001507] was created:
<snip>
> At Tue, 11 Oct 2005 22:34:24 +0200,
> Wolfgang Denk <wd@denx.de> wrote:
>
> > Does that mean that I should ignore the link you posted earlier
> > today?
>
> I cleared up the structure now.
>
> http://www.ludenkalle.de/u-boot/
>
> Has my last clean up effort and the old stuff in deprecated.
> The u-boot-git-20051012.diff is a diff between yesterdays git checkout
> and my actual modifications. the directory content of
> u-boot-git-20051012/ is the same splittet with splitdiff vor viewing
> convenience on a per file basis (so pretty redundant).
>
> > Make sure to include or exactly the needed features only. "all but X"
> > is asking for problems when a new feature Y gets added which is not
> > supported by your board. Rather use "default - M - N + X + Y".
>
> But is
>
> +#define CONFIG_COMMANDS \
> (CONFIG_CMD_DFL\
> & ~CFG_CMD_NET\
> & ~CFG_CMD_IMLS\
>
> [...]
>
> & ~CFG_CMD_MISC\
> | CFG_CMD_CACHE)
>
> not your described way to do this?
>
> > Yes, there are several of these stupidly configured boards which I
> > have to cleanup nearly each time a new command gets added. See
>
> Do you have an example in mind where I should have a look at?
>
> Regards, Konsti
>
> --
> GPG KeyID EF62FCEF
> Fingerprint: 13C9 B16B 9844 EC15 CC2E A080 1E69 3FDA EF62 FCEF
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001491] [U-Boot-Users] [PATCH-8/8]Blackfin support - Add r [...]
From: DENX Support System @ 2006-04-01 1:20 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001491] was created:
<snip>
> The patch is based on following point in the current U-boot git
> repository.
> ============================================================
> commit 6624b687bc2b747233090e67628df37d1c84ed17
> Author: Wolfgang Denk <wd@pollux.(none)>
> Date: Wed Feb 22 10:25:39 2006 +0100
>
> Rename SMMACO4 board into smmaco4 for consistency with Linux.
> ============================================================
> Changelog entry:
> * Added rtc support for Blackfin platform
> Patch by Aubrey.Li <aubreylee@gmail.com>
>
> Thanks,
> -Aubrey
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001534] [U-Boot-Users] mpc83xx flash remapping
From: DENX Support System @ 2006-04-01 1:20 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001534] was created:
<snip>
> Hi.
>
> I found that if the 'generic' cpu/mpc83xx/start.S is changed to comply
> with pre-existing configuration values for flash mapping registers, then
> it is no longer hard-wired to just 8m flash size. This way, each
> implementor does not have to go munging the start.S file, but just has
> to set up correct values for:
>
> CFG_LBLAWAR0_PRELIM
> CFG_OR0_PRELIM
>
> and things get re-mapped ok.
>
> Plz consider attached.
>
> -dbu.
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001516] [U-Boot-Users] [PATCH] SPI relocation fix
From: DENX Support System @ 2006-04-01 1:20 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001516] was created:
<snip>
> Hello David,
>
> If you like, I'd like you to take a look at the patch I submitted to the
>
> list about two months ago. It not only takes care of your problem but
> provides uniform support for various types of parameter area relocations
>
> across all existing MPC8xx CPUs.
>
> I am attaching this patch here, since not all the archives keep the
> patches.
>
> Happy hacking,
> Vladimir
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001525] [U-Boot-Users] [PATCH 03/04] Add Flat Dev Tree con [...]
From: DENX Support System @ 2006-04-01 1:20 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001525] was created:
<snip>
> Jon Loeliger <jdl@freescale.com> writes:
>
>
> > diff --git a/board/mpc8560ads/oftree.dts b/board/mpc8560ads/oftree.dts
> > new file mode 100644
> > index 0000000..4c10564
> > --- /dev/null
> > +++ b/board/mpc8560ads/oftree.dts
> ...
> > + serial at 4500 {
> > + device_type = "serial";
> > + compatible = "ns16550";
> > + reg = <4500 100>; // reg base, size
> > + clock-frequency = <0>; // should we fill in in uboot?
> > + interrupts = <1a 3>;
> > + interrupt-parent = <40000>;
> > + };
> > +
> > + serial at 4600 {
> > + device_type = "serial";
> > + compatible = "ns16550";
> > + reg = <4600 100>; // reg base, size
> > + clock-frequency = <0>; // should we fill in in uboot?
> > + interrupts = <1a 3>;
> > + interrupt-parent = <40000>;
> > + };
>
> Doesn't the 8560 have SCC serial ports only, and not a DUART?
>
> - Nathan
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001543] [U-Boot-Users] [PATCH-3/8]Blackfin support - Add l [...]
From: DENX Support System @ 2006-04-01 1:20 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001543] was created:
<snip>
> The patch is based on following point in the current U-boot git
> repository.
> ============================================================
> commit 6624b687bc2b747233090e67628df37d1c84ed17
> Author: Wolfgang Denk <wd@pollux.(none)>
> Date: Wed Feb 22 10:25:39 2006 +0100
>
> Rename SMMACO4 board into smmaco4 for consistency with Linux.
> ============================================================
>
> Changelog entry:
> * Add lib directory for Blackfin platform.
> Patch by Aubrey.Li <aubreylee@gmail.com>
>
> Thanks,
> -Aubrey
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001552] [U-Boot-Users] [PATCH] EP852 board support
From: DENX Support System @ 2006-04-01 1:20 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001552] was created:
<snip>
> Hello Wolfgang,
>
> This patch adds support for EP852 board from Embedded Planet. It
> requires the previous two patches that I've just sent out to be there.
>
> Changelog entry
>
> * Added support for EP852 board from Embedded Planet
> Patch by Vladimir Gurevich <vag@paulidav.org>
>
> Thanks,
> Vladimir
</snip>
Your U-Boot support team
^ permalink raw reply
* Re: [RESEND][2.6.15] New ATA error messages on upgrade to 2.6.15
From: Robert Hancock @ 2006-04-01 1:21 UTC (permalink / raw)
To: linux-kernel; +Cc: Kyle Moffett
In-Reply-To: <5WB4M-2kX-29@gated-at.bofh.it>
Kyle Moffett wrote:
> hdg: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hdg: dma_intr: error=0x84 { DriveStatusError BadCRC }
Hmm, are these new? Sure you don't have a bad IDE cable?
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/
^ permalink raw reply
* Re: Avoid excessive time spend on concurrent slab shrinking
From: Andrew Morton @ 2006-04-01 1:25 UTC (permalink / raw)
To: Christoph Lameter; +Cc: nickpiggin, linux-mm, Nathan Scott
In-Reply-To: <Pine.LNX.4.64.0603311619590.9173@schroedinger.engr.sgi.com>
Christoph Lameter <clameter@sgi.com> wrote:
>
> Some traces:
>
> Stack traceback for pid 16836
> 0xe00000380bc68000 16836 1 1 6 R
> 0xa00000020b8e6050 [xfs]xfs_iextract+0x190
> 0xa00000020b8e63a0 [xfs]xfs_ireclaim+0x80
> 0xa00000020b921c70 [xfs]xfs_finish_reclaim+0x330
> 0xa00000020b921fa0 [xfs]xfs_reclaim+0x140
> 0xa00000020b93f820 [xfs]linvfs_clear_inode+0x260
> 0xa0000001001855f0 clear_inode+0x310
> 0xa000000100185f70 dispose_list+0x90
> 0xa000000100186c40 shrink_icache_memory+0x480
> 0xa000000100105bb0 shrink_slab+0x290
> 0xa000000100107cc0 try_to_free_pages+0x380
> 0xa0000001000f9f70 __alloc_pages+0x330
> 0xa0000001000ed940 page_cache_alloc_cold+0x160
> 0xa0000001000fe3a0 __do_page_cache_readahead+0x120
> 0xa0000001000fe820 blockable_page_cache_readahead+0xe0
> 0xa0000001000fea50 make_ahead_window+0x150
> 0xa0000001000fee30 page_cache_readahead+0x390
> 0xa0000001000ee730 do_generic_mapping_read+0x190
> 0xa0000001000efd80 __generic_file_aio_read+0x2c0
> 0xa00000020b93c190 [xfs]xfs_read+0x3b0
> 0xa00000020b934170 [xfs]linvfs_aio_read+0x130
OK, thanks. Is that a typical trace?
It appears that we're being busy in xfs_iextract(), but it would be sad if
the problem was really lock contention in xfs_iextract(), and we just
happened to catch it when it was running.
Or maybe xfs_iextract is just slow. So this is one thing we need to get to
the bottom of (profiles might tell us).
Assuming that there's nothing we can do to improve the XFS situation, our
options appear to be, in order of preference:
a) move some/all of dispose_list() outside iprune_mutex.
b) make iprune_mutex an rwlock, take it for reading around
dispose_list(), for writing elsewhere.
c) go back to single-threading shrink_slab (or just shrink_icache_memory())
For this one we'd need to understand which observations prompted Nick
to make shrinker_rwsem an rwsem?
We also need to understand why this has become worse. Perhaps xfs_iextract
got slower (cc's Nathan). Do you have any idea whenabout in kernel history
this started happening?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [uml-devel] Kernel panic - not syncing: Kernel mode signal 7
From: Christopher S. Aker @ 2006-04-01 1:28 UTC (permalink / raw)
To: Blaisorblade; +Cc: user-mode-linux-devel
In-Reply-To: <200604010018.42600.blaisorblade@yahoo.it>
Blaisorblade wrote:
> On Saturday 01 April 2006 00:08, Christopher S. Aker wrote:
>> I'm posting this for posterity. I've asked the user to upgrade to
>> 2.6.16.1-bs1 for now. He's hit this twice in the last month...
>
>> http://www.theshore.net/~caker/uml/kernels/2.6.15-linode16
>
>> Kernel panic - not syncing: Kernel mode signal 7
>
> SIGBUS, aka /tmp (or wherever the memory is hosted, i.e. $TMP) full on the
> host.
>
>> 89ae3778: [<8001f41c>] bus_handler+0x59/0x5b
I mount a tmpfs directory exclusively for each UML the same size as the
mem= parameter. Something fishy is going on with this particular host,
now that I look at the other UML console, a number of them have hit this...
# uname -a
Linux host20.linode.com 2.6.11-rc4-1-bigmem64 #2 SMP Sun Feb 20 04:57:53
EST 2005 i686 i686 i386 GNU/Linux
[root@host20 root]# uptime
20:24:54 up 392 days, 57 min, 4 users, load average: 0.46, 0.56, 0.66
I just noticed one of the drives is failing which has a swap partition
on it. That probably explains it. I'll remove that from the equation.
Thanks,
-Chris
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply
* Re: [PATCH] splice exports
From: Arjan van de Ven @ 2006-04-01 1:33 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Jens Axboe, Andrew Morton, Linus Torvalds, linux-kernel
In-Reply-To: <442DB7F0.8090000@garzik.org>
On Fri, 2006-03-31 at 18:14 -0500, Jeff Garzik wrote:
> Jens Axboe wrote:
> > On Fri, Mar 31 2006, Jeff Garzik wrote:
> >> Jens Axboe wrote:
> >>> On Fri, Mar 31 2006, Arjan van de Ven wrote:
> >>>> On Thu, 2006-03-30 at 23:06 -0500, Jeff Garzik wrote:
> >>>>> Woe be unto he who builds their filesystems as modules.
> >>>> since splice support is highly linux specific and new.. shouldn't these
> >>>> be _GPL exports?
> >>> Yes they should, I'll add that to the current splice tree.
> >> Why? We don't usually restrict filesystems in such ways... I would
> >> rather a binary-only module reference generic_file_splice_read() than
> >> create its own.
> >
> > You could use that very same argument for any piece of the kernel, then,
> > so I don't think that adds much value to _not_ exporting it GPL.
>
> Not really, because I'm considering the Real World(tm) users, not
> abstract theory :) The other filesystem junk is exported non-GPL, and
> existing binary-only filesystems use that stuff.
>
> IOW its a bit rude to say "oh you can have your BO filesystem, just not
> splice support."
it's a bit like saying "you can use all the standard unix interfaces,
but these are very linux specific"; eg the same arguments for making lsm
and other pieces _GPL; they're so linux specific that users that use
these do so with linux in mind etc
^ permalink raw reply
* Re: change lspp ipc auditing
From: Steve Grubb @ 2006-04-01 1:36 UTC (permalink / raw)
To: sds; +Cc: redhat-lspp, linux-audit, James Morris
In-Reply-To: <1143841138.17469.108.camel@moss-spartans.epoch.ncsc.mil>
On Friday 31 March 2006 16:38, Stephen Smalley wrote:
> Why set it to 2?
I sometimes like those things so that I can printk them during debug to see
which one is doing it. If they were both a "1" there's no way to distinguish
which one tripped it.
> BTW, I personally have no strong opinion on whether to call audit_panic
> in this case.
My feeling is that calling audit_panic does no good. In the case of sendfile,
the data has already left the box and panic helps nothing. What we need to do
is figure out how to close the loop manually just in case this ever happens.
Maybe this should be added to the agenda for Monday's lspp telecon?
Thanks,
-Steve
^ permalink raw reply
* Re: SCSI selection issue with aic7xxx_old driver
From: Kevin K @ 2006-04-01 1:36 UTC (permalink / raw)
To: arjan; +Cc: linux-scsi
In-Reply-To: <1143802756.3053.0.camel@laptopd505.fenrus.org>
On Mar 31, 2006, at 4:59 AM, Arjan van de Ven wrote:
> On Wed, 2006-03-29 at 11:51 -0600, Kevin K wrote:
>> I'm in the process up converting from RHEL 2.1 to RHEL 4, and have
>> encountered an issue with the aic7xxx_old driver (5.2.6, as provided
>> with the RH 2.4.9-34 kernel, and with 2.6.15.5 kernel).
>>
>> The SCSI card is an Adaptec 2940U card.
>>
>> Namely, an old SCSI device isn't being seen very often. Maybe 1 in
>> 10 times loading the module. Under the 2.4.18 kernel, it was always
>> seen using this driver except in the case of hardware/cabling issues.
>>
>> With the same hardware and OS, but using the new driver (aic7xxx),
>> the hardware is consistently seen.
>
> well... sounds you have a solution right there... ;)
> the _old driver isn't really actively maintained anymore since... a
> long
> time. At least the "new" one has been getting maintenance
>
Unfortunately, the main reason we've stayed with the old driver was
that an application we inherited didn't work properly at a low level
with the "new" driver, even on versions of the Linux Kernel, such as
2.4.18, that the application worked with the "old" driver.
Now, with attempting to port it to a more modern Linux kernel and
distribution, we appear to have a choice of finally getting it to
work with the new driver, since the old driver isn't seeing the
hardware properly.
We were just hoping to eliminate one stumbling block by remaining
with the old driver. It isn't like we are using modern hardware.
The 2940 is quite old now, and the SCSI device is older still ;)
Thanks,
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: whitespace cleanups (try 2)
From: Nathan Fontenot @ 2006-03-31 21:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
In-Reply-To: <200603311509.25712.nfont@austin.ibm.com>
This patch is nothing but whitespace cleanup for eeh.c. This removes
spaces between function calls and their parameters, edits lines that are
longer than 80 characters and puts function return variables and function
names on one line.
Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
----
Let's try this again with a patch that will apply a little cleaner
Index: kernel/arch/powerpc/platforms/pseries/eeh.c
===================================================================
--- kernel.orig/arch/powerpc/platforms/pseries/eeh.c 2006-03-31 09:02:17.%N
-0600
+++ kernel/arch/powerpc/platforms/pseries/eeh.c 2006-03-31 14:34:43.%N -0600
@@ -111,7 +111,7 @@ static unsigned long slot_resets;
/* --------------------------------------------------------------- */
/* Below lies the EEH event infrastructure */
-void eeh_slot_error_detail (struct pci_dn *pdn, int severity)
+void eeh_slot_error_detail(struct pci_dn *pdn, int severity)
{
int config_addr;
unsigned long flags;
@@ -126,13 +126,10 @@ void eeh_slot_error_detail (struct pci_d
if (pdn->eeh_pe_config_addr)
config_addr = pdn->eeh_pe_config_addr;
- rc = rtas_call(ibm_slot_error_detail,
- 8, 1, NULL, config_addr,
- BUID_HI(pdn->phb->buid),
- BUID_LO(pdn->phb->buid), NULL, 0,
- virt_to_phys(slot_errbuf),
- eeh_error_buf_size,
- severity);
+ rc = rtas_call(ibm_slot_error_detail, 8, 1, NULL, config_addr,
+ BUID_HI(pdn->phb->buid), BUID_LO(pdn->phb->buid),
+ NULL, 0, virt_to_phys(slot_errbuf),
+ eeh_error_buf_size, severity);
if (rc == 0)
log_error(slot_errbuf, ERR_TYPE_RTAS_LOG, 0);
@@ -184,7 +181,7 @@ static inline unsigned long eeh_token_to
return pa | (token & (PAGE_SIZE-1));
}
-/**
+/**
* Return the "partitionable endpoint" (pe) under which this device lies
*/
struct device_node * find_device_pe(struct device_node *dn)
@@ -203,8 +200,7 @@ struct device_node * find_device_pe(stru
* and the slot is frozen, then the driver can deadlock in
* an interrupt context, which is bad.
*/
-
-static void __eeh_mark_slot (struct device_node *dn, int mode_flag)
+static void __eeh_mark_slot(struct device_node *dn, int mode_flag)
{
while (dn) {
if (PCI_DN(dn)) {
@@ -217,13 +213,13 @@ static void __eeh_mark_slot (struct devi
dev->error_state = pci_channel_io_frozen;
if (dn->child)
- __eeh_mark_slot (dn->child, mode_flag);
+ __eeh_mark_slot(dn->child, mode_flag);
}
dn = dn->sibling;
}
}
-void eeh_mark_slot (struct device_node *dn, int mode_flag)
+void eeh_mark_slot(struct device_node *dn, int mode_flag)
{
dn = find_device_pe (dn);
@@ -232,36 +228,36 @@ void eeh_mark_slot (struct device_node *
dn = dn->parent;
PCI_DN(dn)->eeh_mode |= mode_flag;
- __eeh_mark_slot (dn->child, mode_flag);
+ __eeh_mark_slot(dn->child, mode_flag);
}
-static void __eeh_clear_slot (struct device_node *dn, int mode_flag)
+static void __eeh_clear_slot(struct device_node *dn, int mode_flag)
{
while (dn) {
if (PCI_DN(dn)) {
PCI_DN(dn)->eeh_mode &= ~mode_flag;
PCI_DN(dn)->eeh_check_count = 0;
if (dn->child)
- __eeh_clear_slot (dn->child, mode_flag);
+ __eeh_clear_slot(dn->child, mode_flag);
}
dn = dn->sibling;
}
}
-void eeh_clear_slot (struct device_node *dn, int mode_flag)
+void eeh_clear_slot(struct device_node *dn, int mode_flag)
{
unsigned long flags;
spin_lock_irqsave(&confirm_error_lock, flags);
-
+
dn = find_device_pe (dn);
-
+
/* Back up one, since config addrs might be shared */
if (PCI_DN(dn) && PCI_DN(dn)->eeh_pe_config_addr)
dn = dn->parent;
PCI_DN(dn)->eeh_mode &= ~mode_flag;
PCI_DN(dn)->eeh_check_count = 0;
- __eeh_clear_slot (dn->child, mode_flag);
+ __eeh_clear_slot(dn->child, mode_flag);
spin_unlock_irqrestore(&confirm_error_lock, flags);
}
@@ -305,8 +301,8 @@ int eeh_dn_check_failure(struct device_n
pdn->eeh_mode & EEH_MODE_NOCHECK) {
ignored_check++;
#ifdef DEBUG
- printk ("EEH:ignored check (%x) for %s %s\n",
- pdn->eeh_mode, pci_name (dev), dn->full_name);
+ printk("EEH:ignored check (%x) for %s %s\n",
+ pdn->eeh_mode, pci_name(dev), dn->full_name);
#endif
return 0;
}
@@ -327,16 +323,17 @@ int eeh_dn_check_failure(struct device_n
if (pdn->eeh_mode & EEH_MODE_ISOLATED) {
pdn->eeh_check_count ++;
if (pdn->eeh_check_count >= EEH_MAX_FAILS) {
- printk (KERN_ERR "EEH: Device driver ignored %d bad
reads, panicing\n",
- pdn->eeh_check_count);
+ printk(KERN_ERR "EEH: Device driver ignored %d bad "
+ "reads, panicing\n", pdn->eeh_check_count);
dump_stack();
-
+
/* re-read the slot reset state */
if (read_slot_reset_state(pdn, rets) != 0)
rets[0] = -1; /* reset state unknown */
- /* If we are here, then we hit an infinite loop. Stop.
*/
- panic("EEH: MMIO halt (%d) on device:%s\n", rets[0],
pci_name(dev));
+ /* If we're here, then we hit an infinite loop. Stop.
*/+ panic("EEH: MMIO halt (%d) on device:%s\n",
+ rets[0], pci_name(dev));
}
goto dn_unlock;
}
@@ -352,8 +349,8 @@ int eeh_dn_check_failure(struct device_n
/* If the call to firmware failed, punt */
if (ret != 0) {
- printk(KERN_WARNING "EEH: read_slot_reset_state() failed;
rc=%d dn=%s\n",
- ret, dn->full_name);
+ printk(KERN_WARNING "EEH: read_slot_reset_state() failed; "
+ "rc=%d dn=%s\n", ret, dn->full_name);
false_positives++;
rc = 0;
goto dn_unlock;
@@ -361,8 +358,8 @@ int eeh_dn_check_failure(struct device_n
/* If EEH is not supported on this device, punt. */
if (rets[1] != 1) {
- printk(KERN_WARNING "EEH: event on unsupported device, rc=%d
dn=%s\n",
- ret, dn->full_name);
+ printk(KERN_WARNING "EEH: event on unsupported device, rc=%d "
+ "dn=%s\n", ret, dn->full_name);
false_positives++;
rc = 0;
goto dn_unlock;
@@ -384,11 +381,11 @@ int eeh_dn_check_failure(struct device_n
}
slot_resets++;
-
+
/* Avoid repeated reports of this failure, including problems
* with other functions on this device, and functions under
* bridges. */
- eeh_mark_slot (dn, EEH_MODE_ISOLATED);
+ eeh_mark_slot(dn, EEH_MODE_ISOLATED);
spin_unlock_irqrestore(&confirm_error_lock, flags);
state = pci_channel_io_normal;
@@ -396,12 +393,13 @@ int eeh_dn_check_failure(struct device_n
state = pci_channel_io_frozen;
if (rets[0] == 5)
state = pci_channel_io_perm_failure;
- eeh_send_failure_event (dn, dev, state, rets[2]);
+ eeh_send_failure_event(dn, dev, state, rets[2]);
/* Most EEH events are due to device driver bugs. Having
* a stack trace will help the device-driver authors figure
* out what happened. So print that out. */
- if (rets[0] != 5) dump_stack();
+ if (rets[0] != 5)
+ dump_stack();
return 1;
dn_unlock:
@@ -438,7 +436,7 @@ unsigned long eeh_check_failure(const vo
}
dn = pci_device_to_OF_node(dev);
- eeh_dn_check_failure (dn, dev);
+ eeh_dn_check_failure(dn, dev);
pci_dev_put(dev);
return val;
@@ -453,26 +451,29 @@ EXPORT_SYMBOL(eeh_check_failure);
* a number of milliseconds to wait until the PCI slot is
* ready to be used.
*/
-static int
-eeh_slot_availability(struct pci_dn *pdn)
+static int eeh_slot_availability(struct pci_dn *pdn)
{
int rc;
int rets[3];
rc = read_slot_reset_state(pdn, rets);
- if (rc) return rc;
+ if (rc)
+ return rc;
- if (rets[1] == 0) return -1; /* EEH is not supported */
- if (rets[0] == 0) return 0; /* Oll Korrect */
+ if (rets[1] == 0)
+ return -1; /* EEH is not supported */
+ if (rets[0] == 0)
+ return 0; /* Oll Korrect */
if (rets[0] == 5) {
- if (rets[2] == 0) return -1; /* permanently unavailable */
+ if (rets[2] == 0)
+ return -1; /* permanently unavailable */
return rets[2]; /* number of millisecs to wait */
}
if (rets[0] == 1)
return 250;
- printk (KERN_ERR "EEH: Slot unavailable: rc=%d, rets=%d %d %d\n",
+ printk(KERN_ERR "EEH: Slot unavailable: rc=%d, rets=%d %d %d\n",
rc, rets[0], rets[1], rets[2]);
return -1;
}
@@ -486,18 +487,16 @@ eeh_slot_availability(struct pci_dn *pdn
* safe to call in an interrupt context.
*
*/
-
-static void
-rtas_pci_slot_reset(struct pci_dn *pdn, int state)
+static void rtas_pci_slot_reset(struct pci_dn *pdn, int state)
{
int config_addr;
int rc;
- BUG_ON (pdn==NULL);
+ BUG_ON (pdn==NULL);
if (!pdn->phb) {
- printk (KERN_WARNING "EEH: in slot reset, device node %s has
no phb\n",
- pdn->node->full_name);
+ printk(KERN_WARNING "EEH: in slot reset, device node %s "
+ "has no phb\n", pdn->node->full_name);
return;
}
@@ -506,14 +505,13 @@ rtas_pci_slot_reset(struct pci_dn *pdn,
if (pdn->eeh_pe_config_addr)
config_addr = pdn->eeh_pe_config_addr;
- rc = rtas_call(ibm_set_slot_reset,4,1, NULL,
- config_addr,
- BUID_HI(pdn->phb->buid),
- BUID_LO(pdn->phb->buid),
+ rc = rtas_call(ibm_set_slot_reset,4,1, NULL, config_addr,
+ BUID_HI(pdn->phb->buid), BUID_LO(pdn->phb->buid),
state);
if (rc) {
- printk (KERN_WARNING "EEH: Unable to reset the failed slot,
(%d) #RST=%d dn=%s\n",
- rc, state, pdn->node->full_name);
+ printk(KERN_WARNING "EEH: Unable to reset the failed slot, "
+ "(%d) #RST=%d dn=%s\n", rc, state,
+ pdn->node->full_name);
return;
}
}
@@ -523,39 +521,38 @@ rtas_pci_slot_reset(struct pci_dn *pdn,
*
* Return 0 if success, else a non-zero value.
*/
-
-int
-rtas_set_slot_reset(struct pci_dn *pdn)
+int rtas_set_slot_reset(struct pci_dn *pdn)
{
int i, rc;
- rtas_pci_slot_reset (pdn, 1);
+ rtas_pci_slot_reset(pdn, 1);
/* The PCI bus requires that the reset be held high for at least
* a 100 milliseconds. We wait a bit longer 'just in case'. */
#define PCI_BUS_RST_HOLD_TIME_MSEC 250
- msleep (PCI_BUS_RST_HOLD_TIME_MSEC);
-
- /* We might get hit with another EEH freeze as soon as the
+ msleep(PCI_BUS_RST_HOLD_TIME_MSEC);
+
+ /* We might get hit with another EEH freeze as soon as the
* pci slot reset line is dropped. Make sure we don't miss
* these, and clear the flag now. */
- eeh_clear_slot (pdn->node, EEH_MODE_ISOLATED);
+ eeh_clear_slot(pdn->node, EEH_MODE_ISOLATED);
- rtas_pci_slot_reset (pdn, 0);
+ rtas_pci_slot_reset(pdn, 0);
/* After a PCI slot has been reset, the PCI Express spec requires
* a 1.5 second idle time for the bus to stabilize, before starting
* up traffic. */
#define PCI_BUS_SETTLE_TIME_MSEC 1800
- msleep (PCI_BUS_SETTLE_TIME_MSEC);
+ msleep(PCI_BUS_SETTLE_TIME_MSEC);
/* Now double check with the firmware to make sure the device is
* ready to be used; if not, wait for recovery. */
- for (i=0; i<10; i++) {
- rc = eeh_slot_availability (pdn);
+ for (i = 0; i < 10; i++) {
+ rc = eeh_slot_availability(pdn);
if (rc < 0)
- printk (KERN_ERR "EEH: failed (%d) to reset slot
%s\n", rc, pdn->node->full_name);
+ printk(KERN_ERR "EEH: failed (%d) to reset slot %s\n",
+ rc, pdn->node->full_name);
if (rc == 0)
return 0;
if (rc < 0)
@@ -564,9 +561,10 @@ rtas_set_slot_reset(struct pci_dn *pdn)
msleep (rc+100);
}
- rc = eeh_slot_availability (pdn);
+ rc = eeh_slot_availability(pdn);
if (rc)
- printk (KERN_ERR "EEH: timeout resetting slot %s\n",
pdn->node->full_name);
+ printk(KERN_ERR "EEH: timeout resetting slot %s\n",
+ pdn->node->full_name);
return rc;
}
@@ -577,7 +575,7 @@ rtas_set_slot_reset(struct pci_dn *pdn)
* Although firmware will set up BARs during boot, it doesn't
* set up device BAR's after a device reset, although it will,
* if requested, set up bridge configuration. Thus, we need to
- * configure the PCI devices ourselves.
+ * configure the PCI devices ourselves.
*/
/**
@@ -586,12 +584,14 @@ rtas_set_slot_reset(struct pci_dn *pdn)
* the expansion ROM base address, the latency timer, and etc.
* from the saved values in the device node.
*/
-static inline void __restore_bars (struct pci_dn *pdn)
+static inline void __restore_bars(struct pci_dn *pdn)
{
int i;
- if (NULL==pdn->phb) return;
- for (i=4; i<10; i++) {
+ if (NULL==pdn->phb)
+ return;
+
+ for (i = 4; i < 10; i++) {
rtas_write_config(pdn, i*4, 4, pdn->config_space[i]);
}
@@ -601,11 +601,11 @@ static inline void __restore_bars (struc
#define BYTE_SWAP(OFF) (8*((OFF)/4)+3-(OFF))
#define SAVED_BYTE(OFF) (((u8 *)(pdn->config_space))[BYTE_SWAP(OFF)])
- rtas_write_config (pdn, PCI_CACHE_LINE_SIZE, 1,
- SAVED_BYTE(PCI_CACHE_LINE_SIZE));
+ rtas_write_config(pdn, PCI_CACHE_LINE_SIZE, 1,
+ SAVED_BYTE(PCI_CACHE_LINE_SIZE));
- rtas_write_config (pdn, PCI_LATENCY_TIMER, 1,
- SAVED_BYTE(PCI_LATENCY_TIMER));
+ rtas_write_config(pdn, PCI_LATENCY_TIMER, 1,
+ SAVED_BYTE(PCI_LATENCY_TIMER));
/* max latency, min grant, interrupt pin and line */
rtas_write_config(pdn, 15*4, 4, pdn->config_space[15]);
@@ -620,15 +620,15 @@ static inline void __restore_bars (struc
void eeh_restore_bars(struct pci_dn *pdn)
{
struct device_node *dn;
- if (!pdn)
+ if (!pdn)
return;
-
+
if ((pdn->eeh_mode & EEH_MODE_SUPPORTED)
&& !IS_BRIDGE(pdn->class_code))- __restore_bars (pdn);
+ __restore_bars(pdn);
dn = pdn->node->child;
while (dn) {
- eeh_restore_bars (PCI_DN(dn));
+ eeh_restore_bars(PCI_DN(dn));
dn = dn->sibling;
}
}
@@ -645,9 +645,9 @@ static void eeh_save_bars(struct pci_dn
{
int i;
- if (!pdn )
+ if (!pdn)
return;
-
+
for (i = 0; i < 16; i++)
rtas_read_config(pdn, i * 4, 4, &pdn->config_space[i]);
}
@@ -663,13 +663,11 @@ rtas_configure_bridge(struct pci_dn *pdn
if (pdn->eeh_pe_config_addr)
config_addr = pdn->eeh_pe_config_addr;
- rc = rtas_call(ibm_configure_bridge,3,1, NULL,
- config_addr,
- BUID_HI(pdn->phb->buid),
- BUID_LO(pdn->phb->buid));
+ rc = rtas_call(ibm_configure_bridge,3,1, NULL, config_addr,
+ BUID_HI(pdn->phb->buid), BUID_LO(pdn->phb->buid));
if (rc) {
- printk (KERN_WARNING "EEH: Unable to configure device bridge
(%d) for %s\n",
- rc, pdn->node->full_name);
+ printk(KERN_WARNING "EEH: Unable to configure device bridge "
+ "(%d) for %s\n", rc, pdn->node->full_name);
}
}
@@ -750,31 +748,35 @@ static void *early_enable_eeh(struct dev
pdn->eeh_mode |= EEH_MODE_SUPPORTED;
pdn->eeh_config_addr = regs[0];
- /* If the newer, better, ibm,get-config-addr-info is
supported,
- * then use that instead. */
+ /* If the newer, better, ibm,get-config-addr-info
+ * is supported, then use that instead. */
pdn->eeh_pe_config_addr = 0;
if (ibm_get_config_addr_info != RTAS_UNKNOWN_SERVICE)
{
unsigned int rets[2];
- ret = rtas_call (ibm_get_config_addr_info, 4,
2, rets,
- pdn->eeh_config_addr,
- info->buid_hi, info->buid_lo,
- 0);
+ ret = rtas_call(ibm_get_config_addr_info, 4,
2,
+ rets, pdn->eeh_config_addr,
+ info->buid_hi, info->buid_lo,
+ 0);
if (ret == 0)
pdn->eeh_pe_config_addr = rets[0];
}
#ifdef DEBUG
- printk(KERN_DEBUG "EEH: %s: eeh enabled, config=%x
pe_config=%x\n",
- dn->full_name, pdn->eeh_config_addr,
pdn->eeh_pe_config_addr);
+ printk(KERN_DEBUG "EEH: %s: eeh enabled, config=%x "
+ "pe_config=%x\n", dn->full_name,
+ pdn->eeh_config_addr,
pdn->eeh_pe_config_addr);
#endif
} else {
/* This device doesn't support EEH, but it may have an
* EEH parent, in which case we mark it as supported.
*/ if (dn->parent && PCI_DN(dn->parent)
- && (PCI_DN(dn->parent)->eeh_mode &
EEH_MODE_SUPPORTED)) {
+ && (PCI_DN(dn->parent)->eeh_mode
+ & EEH_MODE_SUPPORTED)) {
+
/* Parent supports EEH. */
pdn->eeh_mode |= EEH_MODE_SUPPORTED;
- pdn->eeh_config_addr =
PCI_DN(dn->parent)->eeh_config_addr;
+ pdn->eeh_config_addr =
+ PCI_DN(dn->parent)->eeh_config_addr;
return NULL;
}
}
@@ -818,7 +820,7 @@ void __init eeh_init(void)
ibm_read_slot_reset_state = rtas_token("ibm,read-slot-reset-state");
ibm_slot_error_detail = rtas_token("ibm,slot-error-detail");
ibm_get_config_addr_info = rtas_token("ibm,get-config-addr-info");
- ibm_configure_bridge = rtas_token ("ibm,configure-bridge");
+ ibm_configure_bridge = rtas_token("ibm,configure-bridge");
if (ibm_set_eeh_option == RTAS_UNKNOWN_SERVICE)
return;
@@ -828,8 +830,9 @@ void __init eeh_init(void)
eeh_error_buf_size = 1024;
}
if (eeh_error_buf_size > RTAS_ERROR_LOG_MAX) {
- printk(KERN_WARNING "EEH: rtas-error-log-max is bigger than
allocated "
- "buffer ! (%d vs %d)", eeh_error_buf_size,
RTAS_ERROR_LOG_MAX);
+ printk(KERN_WARNING "EEH: rtas-error-log-max is bigger than "
+ "allocated buffer ! (%d vs %d)", eeh_error_buf_size,
+ RTAS_ERROR_LOG_MAX);
eeh_error_buf_size = RTAS_ERROR_LOG_MAX;
}
@@ -848,7 +851,8 @@ void __init eeh_init(void)
}
if (eeh_subsystem_enabled)
- printk(KERN_INFO "EEH: PCI Enhanced I/O Error Handling
Enabled\n");
+ printk(KERN_INFO "EEH: PCI Enhanced I/O Error Handling "
+ "Enabled\n");
else
printk(KERN_WARNING "EEH: No capable adapters found\n");
}
@@ -925,12 +929,12 @@ static void eeh_add_device_late(struct p
printk(KERN_DEBUG "EEH: adding device %s\n", pci_name(dev));
#endif
- pci_dev_get (dev);
+ pci_dev_get(dev);
dn = pci_device_to_OF_node(dev);
pdn = PCI_DN(dn);
pdn->pcidev = dev;
- pci_addr_cache_insert_device (dev);
+ pci_addr_cache_insert_device(dev);
}
/**
@@ -957,7 +961,7 @@ static void eeh_remove_device(struct pci
dn = pci_device_to_OF_node(dev);
PCI_DN(dn)->pcidev = NULL;
- pci_dev_put (dev);
+ pci_dev_put(dev);
}
void eeh_remove_bus_device(struct pci_dev *dev)
@@ -990,9 +994,9 @@ static int proc_eeh_show(struct seq_file
"eeh_false_positives=%ld\n"
"eeh_ignored_failures=%ld\n"
"eeh_slot_resets=%ld\n",
- no_device, no_dn, no_cfg_addr,
- ignored_check, total_mmio_ffs,
- false_positives, ignored_failures,
+ no_device, no_dn, no_cfg_addr,
+ ignored_check, total_mmio_ffs,
+ false_positives, ignored_failures,
slot_resets);
}
^ permalink raw reply
* Default remote branch for local branch
From: Pavel Roskin @ 2006-04-01 1:48 UTC (permalink / raw)
To: git
Hello!
This is not a ready-to-use proposal, but I think my message can prompt
useful changes in GIT or in the "porcelain".
Let's see how remote changes end up in the head branch of the local
repository (sorry for possible mistakes in terminology):
branch in "remote" local index,
a remote -------> branch -------> branch ------> tree
repository (e.g. origin) (e.g. master)
Brought in sync by:
fetch merge checkout
Relationship stored in:
.git/remotes nowhere!!! .git/HEAD
If I fetch a remote branch, git knows where to get changes. If I change
the current branch, git remembers that. But git doesn't remember the
relationship between branches mirroring the remote branches and branches
used for local development.
There are situations when I want to work for a significant time on a
certain branch. Significant time means that changes are made by
others, and I'm supposed to integrate them and make more changes. Yet I
may want to take advantage of some patches from another team that uses
the other repository.
I want GIT and porcelains work the same way if I'm working with
repository 1 or repository 2. As it stands now, git gives preferential
treatment to the "origin" branch. Whatever branch I'm on, "git-pull"
will pull from "origin". I believe the special role of the "origin"
branch should be reduced to cg-clone and similar commands.
I think it would be convenient to have git remember the remote branch
for the given local branch. git should know that if HEAD points to
"local-B", "git-fetch" should fetch from "remote-B", not from "origin".
To implement this, git would have to implement attributes for local
branches (other ideas are welcome). Currently, there are no attributes
for local branches other than the top SHA1 in .git/refs/heads/
Once at the topic of branch attributes, let's see what else could be
useful? I think that would be the creator of the branch and the comment
(e.g. "this is for tested commits only, to be merged tomorrow" etc).
Where can this data be stored? Probably in blobs pointed to by refs in
e.g. .git/refs/branch-data/ or just in plain files e.g.
under .git/branch-data/
I know, it sounds like a lot of work to save a few keystrokes. But I
think it may be worth it. Working on different branches should have the
same "look and feel". Otherwise, git would repeat a design error of
CVS, where the head branch was given preference e.g. for date based
updates.
I'm sorry, reading this mailing list is beyond my capabilities, so
certain overlaps with other postings may be expected, unless I'm
suggesting something totally off-base :-)
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: snd_pcm_hw_params_get_period_size() returning 0
From: Lee Revell @ 2006-04-01 1:57 UTC (permalink / raw)
To: Carlos Munoz; +Cc: alsa-devel
In-Reply-To: <442DD097.40901@kenati.com>
On Fri, 2006-03-31 at 17:00 -0800, Carlos Munoz wrote:
> Does
> any one know why
> snd_pcm_hw_params_get_period_size() would be returning 0 ? Is it
> something the driver did/didn't do ?
>
Your hw_params callback should have set this to a correct value, try
adding printks.
Lee
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: snd_pcm_hw_params_get_period_size() returning 0
From: Lee Revell @ 2006-04-01 1:59 UTC (permalink / raw)
To: Carlos Munoz; +Cc: alsa-devel
In-Reply-To: <442DD097.40901@kenati.com>
On Fri, 2006-03-31 at 17:00 -0800, Carlos Munoz wrote:
> Does
> any one know why
> snd_pcm_hw_params_get_period_size() would be returning 0 ? Is it
> something the driver did/didn't do ?
>
Argh, please disregard last message, that's not how the hw_params
callback works :-(
Lee
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: addendum: was Re: recovering data on a failed raid-0 installation
From: Technomage @ 2006-04-01 2:01 UTC (permalink / raw)
To: Jeff Breidenbach; +Cc: linux-raid
In-Reply-To: <1143843059.1B7FB4F1@dh11.dngr.org>
Jeff,
I would if I could. but I live on a rather limited income here . :(
also, my chances for employment (other than self-contracted services) in
phoenix are slim and none (being disabled in a market with a very soft tech
sector can lead to that).
now, I don't mean to be abrasive, but, so far, I haven't seen much other than:
1. it can't be done or
2. hire a paid consultant.
as for 1, if a pro can do it, it stands to reason that someone, somewhere (not
a pro) found the way and made his millions on it.
as for 2, not going to be possible on $600.00 a month.
On Friday 31 March 2006 15:10, Jeff Breidenbach wrote:
> Technomage, I recommend hiring a paid consultant; your attitude is a
> little too abrasive for a communal support channel.
^ permalink raw reply
* Re: addendum: was Re: recovering data on a failed raid-0 installation
From: Technomage @ 2006-04-01 2:07 UTC (permalink / raw)
To: Mike Hardy; +Cc: linux-raid
In-Reply-To: <442DB358.1010402@h3c.com>
mike,
yeah.... coaxing the FS into trying to recover seems to be the sticky bit. :(
I have tried all that I know, which is not much considering that this is not
my specialty (I am a unix security admin <unemployed on disability>).
we still have the original drives and we have a drive imaging device arriving
(should have been here today). I can only hope that it will be able to
overcome the problems I have seen with that particular laptop and its "flaky"
IDE subsystem.
only problem with the backups, there were none (no spare drives and the person
that did the setup hadn't realized until too late that there was an incipient
problem with the hardware. :(
if the drive imager is successful in recovering the entire contents of the
drive (he is a forensics specialist and I am retraining to be one) then we
are in business. however, if not. call it a write off and move on I guess. :(
thanks for responding though.....
On Friday 31 March 2006 15:55, you wrote:
> You were in the right spot, I think raid-0 is just a data-lossy format
> and my first impression of your post was "well, don't pick raid-0, duh"
> - not in a rude way just that you got the defined behavior of the
> system, data loss on any failure
>
> I can't imagine how to coax a filesystem to work when it's missing half
> it's contents, but maybe a combination of forcing a start on the raid
> and read-only FS mounts could make it hobble along.
>
> I'd restore from backup and be done with it though
>
> -Mike
>
> Technomage wrote:
> > well? are you guys tapped out on this or should I be looking elsewhere?
> >
> > The *was* the recommended place to seek out help.
> >
> > still waiting........
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Compaq Fiber Channel Array RM4000 / 2.6.16 kernel patch VER6
From: James Bottomley @ 2006-04-01 2:07 UTC (permalink / raw)
To: Ingo Flaschberger; +Cc: Linux-SCSI Mailing List
In-Reply-To: <Pine.GSO.4.64.0604010312590.4531@filebunker.xip.at>
On Sat, 2006-04-01 at 03:16 +0200, Ingo Flaschberger wrote:
> I have looked around in the kernel but I get no idea how to inform the
> block layer about the limit.
> Please advise.
OK, try this out. It places the sector limit in the block queue. I
also removed all the superfluous condition braces and tried to change
the comments to match what you're doing (the block size is actually in
multiples of 512 bytes, so the limit you impose is actually 512 *blocks*
or 256kB).
James
Index: BUILD-2.6/drivers/scsi/scsi.c
===================================================================
--- BUILD-2.6.orig/drivers/scsi/scsi.c 2006-03-30 23:19:20.000000000 -0600
+++ BUILD-2.6/drivers/scsi/scsi.c 2006-03-31 19:48:54.000000000 -0600
@@ -565,7 +565,8 @@
/*
* If SCSI-2 or lower, store the LUN value in cmnd.
*/
- if (cmd->device->scsi_level <= SCSI_2) {
+ if (cmd->device->scsi_level <= SCSI_2 &&
+ cmd->device->scsi_level != SCSI_UNKNOWN) {
cmd->cmnd[1] = (cmd->cmnd[1] & 0x1f) |
(cmd->device->lun << 5 & 0xe0);
}
Index: BUILD-2.6/drivers/scsi/scsi_devinfo.c
===================================================================
--- BUILD-2.6.orig/drivers/scsi/scsi_devinfo.c 2006-03-30 17:31:53.000000000 -0600
+++ BUILD-2.6/drivers/scsi/scsi_devinfo.c 2006-03-31 19:47:06.000000000 -0600
@@ -132,7 +132,9 @@
{"CMD", "CRA-7280", NULL, BLIST_SPARSELUN}, /* CMD RAID Controller */
{"CNSI", "G7324", NULL, BLIST_SPARSELUN}, /* Chaparral G7324 RAID */
{"CNSi", "G8324", NULL, BLIST_SPARSELUN}, /* Chaparral G8324 RAID */
- {"COMPAQ", "LOGICAL VOLUME", NULL, BLIST_FORCELUN},
+ {"COMPAQ", "ARRAY CONTROLLER", NULL, BLIST_SPARSELUN | BLIST_LARGELUN |
+ BLIST_MAX_512 | BLIST_REPORTLUN2}, /* Compaq RA4x00 */
+ {"COMPAQ", "LOGICAL VOLUME", NULL, BLIST_FORCELUN | BLIST_MAX_512K}, /* Compaq RA4x00 */
{"COMPAQ", "CR3500", NULL, BLIST_FORCELUN},
{"COMPAQ", "MSA1000", NULL, BLIST_SPARSELUN | BLIST_NOSTARTONADD},
{"COMPAQ", "MSA1000 VOLUME", NULL, BLIST_SPARSELUN | BLIST_NOSTARTONADD},
Index: BUILD-2.6/drivers/scsi/scsi_scan.c
===================================================================
--- BUILD-2.6.orig/drivers/scsi/scsi_scan.c 2006-03-30 17:31:53.000000000 -0600
+++ BUILD-2.6/drivers/scsi/scsi_scan.c 2006-03-31 19:50:29.000000000 -0600
@@ -673,6 +673,7 @@
case TYPE_MEDIUM_CHANGER:
case TYPE_ENCLOSURE:
case TYPE_COMM:
+ case TYPE_RAID:
case TYPE_RBC:
sdev->writeable = 1;
break;
@@ -738,6 +739,13 @@
sdev->select_no_atn = 1;
/*
+ * Maximum 512 sector transfer length
+ * broken RA4x00 Compaq Disk Array
+ */
+ if (*bflags & BLIST_MAX_512)
+ blk_queue_max_sectors(sdev->request_queue, 512);
+
+ /*
* Some devices may not want to have a start command automatically
* issued when a device is added.
*/
@@ -1123,10 +1131,13 @@
* Also allow SCSI-2 if BLIST_REPORTLUN2 is set and host adapter does
* support more than 8 LUNs.
*/
- if ((bflags & BLIST_NOREPORTLUN) ||
- starget->scsi_level < SCSI_2 ||
- (starget->scsi_level < SCSI_3 &&
- (!(bflags & BLIST_REPORTLUN2) || shost->max_lun <= 8)) )
+ if (bflags & BLIST_NOREPORTLUN)
+ return 1;
+ if (starget->scsi_level < SCSI_2 &&
+ starget->scsi_level != SCSI_UNKNOWN)
+ return 1;
+ if (starget->scsi_level < SCSI_3 &&
+ (!(bflags & BLIST_REPORTLUN2) || shost->max_lun <= 8))
return 1;
if (bflags & BLIST_NOLUN)
return 0;
Index: BUILD-2.6/include/scsi/scsi_devinfo.h
===================================================================
--- BUILD-2.6.orig/include/scsi/scsi_devinfo.h 2006-03-30 17:32:02.000000000 -0600
+++ BUILD-2.6/include/scsi/scsi_devinfo.h 2006-03-31 19:46:46.000000000 -0600
@@ -28,4 +28,5 @@
#define BLIST_NO_ULD_ATTACH 0x100000 /* device is actually for RAID config */
#define BLIST_SELECT_NO_ATN 0x200000 /* select without ATN */
#define BLIST_RETRY_HWERROR 0x400000 /* retry HARDWARE_ERROR */
+#define BLIST_MAX_512 0x800000 /* maximum 512 sector cdb length */
#endif
^ permalink raw reply
* Re: [KJ][Patch] fix kbuild warning in sisfb.o
From: Darren Jenkins\ @ 2006-04-01 2:12 UTC (permalink / raw)
To: kernel-janitors
In-Reply-To: <1143810678.7834.13.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]
Sam
I don't know weather you are aware of this one yet, but we have just
found an issue where 'struct pci_device_id' should be marked
__devinitdata (see Documentation/pci.txt) as the pci code apparently
only uses it in the driver initialisation, but the 'struct pci_driver'
will still hold a pointer to it, giving a kbuild warning. See below.
This definitely looks like a false positive that should be removed.
Darren Jenkins
On Fri, 2006-03-31 at 09:00 -0800, Greg KH wrote:
> On Sat, Apr 01, 2006 at 12:11:18AM +1100, Darren Jenkins" wrote:
> > G'day list
> >
> > This one was a lot harder to find, but much easier to fix.
> >
> > WARNING: drivers/video/sis/sisfb.o - Section mismatch: reference
> > to .init.data: from .data between 'sisfb_driver' (at offset 0xf8) and
> > 'sisfb_ops'
> >
> >
> > This is caused by the 'pci_driver struct' in sis_main.c having a pointer
> > to a 'pci_device_id struct' in 'sis_main.h' that is marked as
> > __devinitdata.
> >
> > The patch below just removes the __devinitdata annotation from the
> > 'pci_device_id struct', which seems like the best solution here.
>
> No, this should be just fine. devinitdata should be just fine for PCI
> device ids.
>
> thanks,
>
> greg k-h
[-- Attachment #2: Type: text/plain, Size: 168 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply
* Re: Synchronizing Bit operations V2
From: Nick Piggin @ 2006-04-01 2:16 UTC (permalink / raw)
To: Christoph Lameter
Cc: davem, Chen, Kenneth W, Zoltan Menyhart, Boehm, Hans,
Grundler, Grant G, akpm, linux-kernel, linux-ia64
In-Reply-To: <Pine.LNX.4.64.0603311327050.8126@schroedinger.engr.sgi.com>
Christoph Lameter wrote:
> On Fri, 31 Mar 2006, Chen, Kenneth W wrote:
>
>
>>>I think we could say that lock semantics are different from barriers. They
>>>are more like acquire and release on IA64. The problem with smb_mb_*** is
>>>that the coder *explicitly* requested a barrier operation and we do not
>>>give it to him.
>>
>>I was browsing sparc64 code and it defines:
>>
>>include/asm-sparc64/bitops.h:
>>#define smp_mb__after_clear_bit() membar_storeload_storestore()
>>
>>With my very naïve knowledge of sparc64, it doesn't look like a full barrier.
>>Maybe sparc64 is broken too ...
>
>
> Dave, how does sparc64 handle this situation?
It looks like sparc64 always expects paired smp_mb__* operations,
before and after the clear_bit.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply
* Re: Synchronizing Bit operations V2
From: Nick Piggin @ 2006-04-01 2:16 UTC (permalink / raw)
To: Christoph Lameter
Cc: davem, Chen, Kenneth W, Zoltan Menyhart, Boehm, Hans,
Grundler, Grant G, akpm, linux-kernel, linux-ia64
In-Reply-To: <Pine.LNX.4.64.0603311327050.8126@schroedinger.engr.sgi.com>
Christoph Lameter wrote:
> On Fri, 31 Mar 2006, Chen, Kenneth W wrote:
>
>
>>>I think we could say that lock semantics are different from barriers. They
>>>are more like acquire and release on IA64. The problem with smb_mb_*** is
>>>that the coder *explicitly* requested a barrier operation and we do not
>>>give it to him.
>>
>>I was browsing sparc64 code and it defines:
>>
>>include/asm-sparc64/bitops.h:
>>#define smp_mb__after_clear_bit() membar_storeload_storestore()
>>
>>With my very naïve knowledge of sparc64, it doesn't look like a full barrier.
>>Maybe sparc64 is broken too ...
>
>
> Dave, how does sparc64 handle this situation?
It looks like sparc64 always expects paired smp_mb__* operations,
before and after the clear_bit.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply
* Re: snd_pcm_hw_params_get_period_size() returning 0
From: Carlos Munoz @ 2006-04-01 2:20 UTC (permalink / raw)
To: Lee Revell; +Cc: alsa-devel
In-Reply-To: <1143856796.2885.4.camel@mindpipe>
Lee Revell wrote:
>On Fri, 2006-03-31 at 17:00 -0800, Carlos Munoz wrote:
>
>
>>Does
>>any one know why
>>snd_pcm_hw_params_get_period_size() would be returning 0 ? Is it
>>something the driver did/didn't do ?
>>
>>
>>
>
>Argh, please disregard last message, that's not how the hw_params
>callback works :-(
>
>Lee
>
>
>
Hi Lee,
I digged further and this is what I found.
snd_pcm_hw_params_get_period_size(...., int *val) does retrieve the
correct period size and updates val with it. However, val does not match
the address passed to it. I mean the caller of
snd_pcm_hw_params_get_period_size(.... 0x41becc) passes the address of
where the period size is to be stored as 0x41becc but
snd_pcm_hw_params_get_period_size() gets 0x7b83c0d8 and that's where it
puts the period size.
This is on the Renesas SH7343 processor. alsa-lib is a dynamic library.
Should I expect the variable address be the same ?
Thanks,
Carlos
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: socket error
From: Stuart Longland @ 2006-04-01 2:31 UTC (permalink / raw)
To: gowri; +Cc: linux-mips
In-Reply-To: <1143426101.3028.9.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]
Gowri Satish Adimulam wrote:
> Hi all ,
> Below iam trying to run ftp server daemon ,
> it gave below message ,
>
> # ./ftpd
> 421 Cannot getsockname( STDIN ), errno=95
> May 6 05:55:54 in.ftpd[48]: Cannot getsockname( STDIN ): Socket
> operation on nt#
>
> any idea about this error .
Yes... two suggestions:
(1) You'll get _much_ better support if you ask the right people -- try
reading the documentation for that FTP daemon -- it should mention who
to contact regarding bugs there.
(2) It looks like it's expecting to be run from inetd/xinetd -- perhaps
that's worth a try?
This list has nothing to do with FTP daemons -- unless you're having
problems getting to ftp.linux-mips.org -- then we might have something
to do with it. But otherwise, it's really not our issue.
--
Stuart Longland (aka Redhatter) .'''.
Gentoo Linux/MIPS Cobalt and Docs Developer '.'` :
. . . . . . . . . . . . . . . . . . . . . . .'.'
http://dev.gentoo.org/~redhatter :.'
International Asperger's Year (1906 ~ 2006)
http://dev.gentoo.org/~redhatter/iay
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.