* Re: [Qemu-devel] Configure doesn't honour CC variable
From: Jamie Lokier @ 2006-06-04 16:25 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <448304D8.7080308@bandsman.co.uk>
Nigel Horne wrote:
> When running "configure" I get
>
> 'ERROR: "gcc" looks like gcc 4.x'
>
> even though I've set the CC environment variable to point to my copy of
> gcc version 3.2.2
Qemu's configure is not like most other configure scripts.
You have to use the --cc="$CC" command line option to Qemu's configure,
to get it to use a different compiler.
You might need to use the --host-cc="$CC" option as well.
-- Jamie
^ permalink raw reply
* Re: [LARTC] Re: For leaf classes is best PFIFO or SFQ?
From: Kajetan Staszkiewicz @ 2006-06-04 16:27 UTC (permalink / raw)
To: lartc
In-Reply-To: <e5oqkf$9f8$1@sea.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1210 bytes --]
Dnia piątek, 2 czerwca 2006 13:09, Stefano Mainardi napisał(a):
> 2006/6/2, Jarek Poplawski <jarkap@poczta.onet.pl>:
> > Stefano Mainardi wrote:
> > > Hi to all,
> > > i'm following this guide (http://www.opalsoft.net/qos/DS-28.htm), is
> > > very detailed, but i'm a bit confused about queuing disciplinse of
> > > leaf classes.
> > >
> > > In this guide the author uses PFIFO (see the scheme that i attached at
> > > message) in this way:
> > >
> > > # tc class add dev eth0 parent 1:21 handle 210: pfifo lmit 10
^^^^^
> >
> > rather that way:
> >
> > # tc qdisc add dev eth0 parent 1:21 handle 210: pfifo limit 10
^^^^^
>
> therefore??? I do not understand ...
Well, pfifo is a discipline at the end of class, not the class.
I'm using sfq for every customer (the are limited to 256/384/512kbit), so they
will be able to use the Internet even when using p2p programs.
--
| pozdrawiam / greetings | powered by Trustix, Gentoo and FreeBSD |
| Kajetan Staszkiewicz | jabber,email,www: vegeta()tuxpowered net |
| Vegeta | IMQ devnames: http://www.tuxpowered.net |
`------------------------^------------------------------------------'
[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 143 bytes --]
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
From: John Que @ 2006-06-04 16:29 UTC (permalink / raw)
To: Oliver Neukum
Cc: Daniel Drake, linux-usb-devel, John W. Linville, netdev,
Ulrich Kunitz
In-Reply-To: <200606040025.32275.oliver@neukum.org>
Hello,
I must confess I don't know much about the ZyDas driver and the rewrite
dirver, but folliowing this post I looked a bit at the code (of both
zd1211 and the rewrite version) and I have a little question; this may
be
seen as a (little) off topic but I will be happy if somebody will
raise this coin.
I had noticed that the zd1211 driver does call request_irq() in zd1205_open(),
file zd1205.c; grepping for request_irq() in the rewrite driver yields
no results.
(I looked at the rewrite version from a week ago but in this point it
is probably the
same).
Why is this so ? I assume that the softmac layer does not call request_irq() on
behalf of the driver because this is not supposed to be like it, as I understand
its functionality. Can anybody briefly calrify this point ?
Regards,
John
On 6/4/06, Oliver Neukum <oliver@neukum.org> wrote:
> Am Samstag, 3. Juni 2006 21:35 schrieb Daniel Drake:
> > Oliver Neukum wrote:
> > > +static int read_mac_addr(struct zd_chip *chip, u8 *mac_addr)
> > > +{
> > > + static const zd_addr_t addr[2] = { CR_MAC_ADDR_P1, CR_MAC_ADDR_P2 };
> > > + return _read_mac_addr(chip, mac_addr, (const zd_addr_t *)addr);
> > > +}
> > >
> > > Why on the stack?
> >
> > Technically it's not on the stack because it is static const (it goes in
> > rodata), but I don't think that this invalidates your point. What's the
> > alternative? kmalloc and kfree every time?
>
> In this case rodata will work. However, if you ever switch to direct DMA
> it will fail. I really did overlook the const keyword.
>
> [..]
> > > +static void disconnect(struct usb_interface *intf)
> > > This is racy. It allows io to disconnected devices. You must take the
> > > lock and set a flag that you test after you've taken the lock elsewhere.
> >
> > Will fix, thanks.
>
> You're welcome
>
> Regards
> Oliver
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" 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: SMP HT + USB2.0 crash
From: Alistair John Strachan @ 2006-06-04 16:30 UTC (permalink / raw)
To: davor emard; +Cc: linux-kernel
In-Reply-To: <beee72200606040923h670cf61dn22a61518ef94013f@mail.gmail.com>
On Sunday 04 June 2006 17:23, davor emard wrote:
[snip]
> > Secondly, I highly recommend running memtest86 on your system for at
> > least a couple of passes. You can download an ISO from the homepage and
> > boot it from a CD. If this fails, you have faulty memory.
>
> hmm I don't know why I didn't use memtest86. but I usually test memory on
> new machine linux, by continuously gzip-ing and ungzip-ing
> 4GB file for 2 days and verify if the beginning
> and the end file are the same memory, CPU and a bit of
> hardware handling them together should be good...
The reason I'm suggesting memtest86, is that it can detect very subtle errors
(gzip will not do this). The crash you're experiencing is in core kernel
code, and it is very unlikely to be a real bug.
This is why Con and myself have suggested to reproduce without the binary
junk, and why bad memory could be a very probable cause.
--
Cheers,
Alistair.
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
^ permalink raw reply
* RE: [LARTC] Not understanding network setup!!
From: ramsurrunv @ 2006-06-04 16:31 UTC (permalink / raw)
To: lartc
In-Reply-To: <1154.202.123.9.97.1149188252.squirrel@mx.uom.ac.mu>
Hi Martin,
> How many times (or how quickly) do you need to do this? I have a
> somewhat simple-minded solution for you, but it doesn't scale, and
> may not actually solve you problem(s).
I actually need this for as long as the machine communicates with other PCs.
> If you are looking at inbound traffic to one of your servers, that
> can be a bit trickier.
I have to capture those three packets for each and every TCP stream that
is initiated. Also, I'm looking only for outbound communication, i.e
emanating from the PC on which I'm trying to catch the packets. So the ACK
packet will be generated on the PC itself. But the problem how do I
capture that particular ACK packet and not the other ACK packets during
data transfer phase, w/o keeping track of IP address/port no. pairs.
Warm regards,
Visham
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: [patch 2/5] [PREEMPT_RT] Changing interrupt handlers from running in thread to hardirq and back runtime.
From: Esben Nielsen @ 2006-06-04 17:33 UTC (permalink / raw)
To: rostedt; +Cc: Esben Nielsen, linux-kernel, Ingo Molnar
In-Reply-To: <1149366105.13993.115.camel@localhost.localdomain>
On Sat, 3 Jun 2006, Steven Rostedt wrote:
> Disclaimer: I haven't read all your patches yet. I'm going one at a
> time to comment, and then I will probably send more emails about the
> overall response. So now, my comments are not on the big picture, but
> simple atomic views.
>
> On Fri, 2006-06-02 at 23:23 +0100, Esben Nielsen wrote:
>> This patch makes it possible to change which context the interrupt handlers
>> for each interrupt run in, hard-irq or threaded if CONFIG_PREEMPT_HARDIRQS is
>> set.
>>
>> The interface is the file
>> /proc/irq/<irq number>/threaded
>> You can read it to see what the context is now or write one of
>>
>> irq
>> fifo <rt priority>
>> rr <rt priority>
>> normal <nice value>
>> batch <nice value>
>>
>> where one of the latter makes the interrupt handler threaded.
>>
>> A replacement for request_irq(), called request_irq2(), is added. When a driver
>
> request_irq2 ... yuck! Perhaps request_irq_convertible() or something
> similar? But irq2, no way!
I know...
The problem is:
1) Don't change existing drivers.
2) The change_irq_context() call-back must be set at request_irq(), so it
it is not enough to just make a new function where the driver can set it's
the callback after the request_irq().
request_irq_convertible() might be an ok name.
>
>> uses this to install it's irq-handler it can also give a change_irq_context
>> call-back. This call-back is called whenever the irq-context is changed or
>> going to be changed. The call-back must be of the form
>>
>> int driver_change_context(int irq, void *dev_id, enum change_context_cmd cmd)
>
> Eeee, looks like a big change to make on drivers, and something that can
> keep -rt from mainline forever. But I'll see more as I read. This
> looks optional but still it will make things more complex.
It is only optional, but the function is very easy to make.
>
>>
>> where
>>
>> enum change_context_cmd {
>> IRQ_TO_HARDIRQ,
>> IRQ_CAN_THREAD,
>> IRQ_TO_THREADED
>> };
>>
>> The call-back is supposed to do the following on
>> IRQ_TO_HARDIRQ: make sure everything in the interrupt handler is non-blocking
>> or return a non-zero error code.
>> IRQ_CAN_THREAD: Return 0 if it is ok for the interrupt handler to be run in
>> thread context. Return a non-zero error code otherwise.
>> IRQ_TO_THREAD: Now the interrupt handler does run in thread context. The
>> driver can now change it's locks to being mutexes. The return
>> value is ignored as the driver already got a chance to protest
>> above.
>>
>> Index: linux-2.6.16-rt23.spin_mutex/include/linux/interrupt.h
>> ===================================================================
>> --- linux-2.6.16-rt23.spin_mutex.orig/include/linux/interrupt.h
>> +++ linux-2.6.16-rt23.spin_mutex/include/linux/interrupt.h
>> @@ -34,21 +34,38 @@ typedef int irqreturn_t;
>> #define IRQ_HANDLED (1)
>> #define IRQ_RETVAL(x) ((x) != 0)
>>
>> +enum change_context_cmd {
>> + IRQ_TO_HARDIRQ,
>> + IRQ_CAN_THREAD,
>> + IRQ_TO_THREADED
>> +};
>> +
>> struct irqaction {
>> irqreturn_t (*handler)(int, void *, struct pt_regs *);
>> unsigned long flags;
>> cpumask_t mask;
>> const char *name;
>> void *dev_id;
>> +#ifdef CONFIG_CHANGE_IRQ_CONTEXT
>> + int (*change_context)(int, void *,
>> + enum change_context_cmd);
>> +#endif
>> struct irqaction *next;
>> int irq;
>> - struct proc_dir_entry *dir, *threaded;
>> + struct proc_dir_entry *dir;
>> + struct rcu_head rcu;
>> };
>>
>> extern irqreturn_t no_action(int cpl, void *dev_id, struct pt_regs *regs);
>> extern int request_irq(unsigned int,
>> irqreturn_t (*handler)(int, void *, struct pt_regs *),
>> unsigned long, const char *, void *);
>> +extern int request_irq2(unsigned int irq,
>> + irqreturn_t (*handler)(int, void *, struct pt_regs *),
>> + unsigned long irqflags, const char * devname,
>> + void *dev_id,
>> + int (*change_context)(int, void *,
>> + enum change_context_cmd));
>> extern void free_irq(unsigned int, void *);
>>
>>
>> Index: linux-2.6.16-rt23.spin_mutex/include/linux/irq.h
>> ===================================================================
>> --- linux-2.6.16-rt23.spin_mutex.orig/include/linux/irq.h
>> +++ linux-2.6.16-rt23.spin_mutex/include/linux/irq.h
>> @@ -47,6 +47,18 @@
>> # define SA_NODELAY 0x01000000
>> #endif
>>
>> +#ifndef SA_MUST_THREAD
>> +# define SA_MUST_THREAD 0x02000000
>> +#endif
>> +
>> +/* Set this flag if the irq handler must thread under preempt-rt otherwise not
>> + */
>> +#ifdef CONFIG_PREEMPT_RT
>> +# define SA_MUST_THREAD_RT SA_MUST_THREAD
>> +#else
>> +# define SA_MUST_THREAD_RT 0
>> +#endif
>> +
>> /*
>> * IRQ types
>> */
>> @@ -147,12 +159,13 @@ struct irq_type {
>> * @chip: low level hardware access functions - comes from type
>> * @action: the irq action chain
>> * @status: status information
>> + * (protected by the spinlock )
>> * @depth: disable-depth, for nested irq_disable() calls
>> * @irq_count: stats field to detect stalled irqs
>> * @irqs_unhandled: stats field for spurious unhandled interrupts
>> * @thread: Thread pointer for threaded preemptible irq handling
>> * @wait_for_handler: Waitqueue to wait for a running preemptible handler
>> - * @lock: locking for SMP
>> + * @lock: lock around the action list
>> * @move_irq: Flag need to re-target interrupt destination
>> *
>> * Pad this out to 32 bytes for cache and indexing reasons.
>> Index: linux-2.6.16-rt23.spin_mutex/kernel/Kconfig.preempt
>> ===================================================================
>> --- linux-2.6.16-rt23.spin_mutex.orig/kernel/Kconfig.preempt
>> +++ linux-2.6.16-rt23.spin_mutex/kernel/Kconfig.preempt
>> @@ -119,6 +119,17 @@ config PREEMPT_HARDIRQS
>>
>> Say N if you are unsure.
>>
>> +config CHANGE_IRQ_CONTEXT
>> + bool "Change the irq context runtime"
>> + depends on PREEMPT_HARDIRQS && (PREEMPT_RCU || !SPIN_MUTEXES)
>> + help
>> + You can change wether the IRQ handler(s) for each IRQ number is
>> + running in hardirq context or as threaded by writing to
>> + /proc/irq/<number>/threaded
>> + If PREEMPT_RT is selected the drivers involved must be ready for it,
>> + though, or the write will fail. Remember to switch on SPIN_MUTEXES as
>> + well in that case as the drivers which are ready uses spin-mutexes.
>> +
>> config SPINLOCK_BKL
>> bool "Old-Style Big Kernel Lock"
>> depends on (PREEMPT || SMP) && !PREEMPT_RT
>> Index: linux-2.6.16-rt23.spin_mutex/kernel/irq/internals.h
>> ===================================================================
>> --- linux-2.6.16-rt23.spin_mutex.orig/kernel/irq/internals.h
>> +++ linux-2.6.16-rt23.spin_mutex/kernel/irq/internals.h
>> @@ -22,6 +22,10 @@ static inline void end_irq(irq_desc_t *d
>> }
>>
>> #ifdef CONFIG_PROC_FS
>> +#ifdef CONFIG_CHANGE_IRQ_CONTEXT
>> +extern int make_irq_nodelay(int irq, struct irq_desc *desc);
>> +extern int make_irq_threaded(int irq, struct irq_desc *desc);
>> +#endif
>> extern void register_irq_proc(unsigned int irq);
>> extern void register_handler_proc(unsigned int irq, struct irqaction *action);
>> extern void unregister_handler_proc(unsigned int irq, struct irqaction *action);
>> Index: linux-2.6.16-rt23.spin_mutex/kernel/irq/manage.c
>> ===================================================================
>> --- linux-2.6.16-rt23.spin_mutex.orig/kernel/irq/manage.c
>> +++ linux-2.6.16-rt23.spin_mutex/kernel/irq/manage.c
>> @@ -206,6 +206,153 @@ int can_request_irq(unsigned int irq, un
>> return !action;
>> }
>>
>> +
>> +#ifdef CONFIG_CHANGE_IRQ_CONTEXT
>> +int make_action_nodelay(int irq, struct irqaction *act)
>> +{
>> + unsigned long flags;
>> +
>> + if(!(act->flags & SA_MUST_THREAD)) {
>> + return 0;
>> + }
>
> Remove the brackets.
>
> Also, let me get this straight. If the action does not have
> SA_MUST_THREAD, we return? Or does it mean that if SA_MUST_THREAD is
> not set, then SA_NODELAY must already be set? If that is the case, then
> why are we not checking for SA_NODELAY here?
If SA_MUST_THREAD is not set, there is no blocking inside the action
handler and therefore it is ok to do this in hardirq aka "nodelay".
Notice SA_MUST_THREAD is set on all handlers in without SA_NODELAY under
PREEMPT_RT.
>
>> +
>> + if( act->change_context ) {
>> + int ret =
>> + act->change_context(irq, act->dev_id, IRQ_TO_HARDIRQ);
>> + if(ret) {
>> + printk(KERN_ERR "Failed to change irq handler "
>> + "for dev %s on IRQ%d to hardirq "
>> + "context (ret: %d)\n", act->name, irq, ret);
>> + return ret;
>> + }
>> + spin_lock_irqsave(&irq_desc[irq].lock, flags);
>> + act->flags &=~SA_MUST_THREAD;
>
> Both flags are zero here (see below about the WARN_ON)
>
The WARN_ON is a warning on both flags set (or supposed to be...:-)
It doesn't make sense to have SA_MUST_THREAD and SA_NODELAY both set.
>> + act->flags |= SA_NODELAY;
>> + spin_unlock_irqrestore(&irq_desc[irq].lock, flags);
>> + return 0;
>> + }
>> + else {
>> + printk(KERN_ERR "Irq handler "
>> + "for dev %s on IRQ%d can not be changed"
>> + " to hardirq context\n", act->name, irq);
>> + return -ENOSYS;
>> + }
>> +
>> +}
>> +
>> +
>> +static int __make_irq_threaded(int irq, struct irq_desc *desc);
>> +
>> +int make_irq_nodelay(int irq, struct irq_desc *desc)
>> +{
>> + int ret = 0;
>> + struct irqaction *act;
>> + unsigned long flags;
>> +
>> + rcu_read_lock();
>> + for(act = desc->action; act; act = act->next) {
>> + WARN_ON(((~act->flags) & (SA_MUST_THREAD|SA_NODELAY)) == 0);
>
> This WARN_ON is not protected by the descriptor lock, so if this
> function is run on two CPUs at the same time, then the act->flags can
> have both of these zero by the above code.
Both be set :-) But bug noticed.
>
>> + if(act->flags & SA_MUST_THREAD) {
>> + ret = make_action_nodelay(irq, act);
>> + if(ret) {
>> + printk(KERN_ERR "Could not make irq %d "
>> + "nodelay (errno %d)\n",
>> + irq, ret);
>
> We printk on failure from above, and then printk again here?
Well might be too verbose.
>
>> + goto failed;
>> + }
>> + }
>> + }
>> + spin_lock_irqsave(&desc->lock, flags);
>> + desc->status |= IRQ_NODELAY;
>> + spin_unlock_irqrestore(&desc->lock, flags);
>> + rcu_read_unlock();
>> +
>> + return 0;
>> + failed:
>> + __make_irq_threaded(irq, desc);
>> + rcu_read_unlock();
>> + return ret;
>> +}
>> +
>> +int action_may_thread(int irq, struct irqaction *act)
>> +{
>> + if(!act->change_context)
>> + return !(act->flags & SA_NODELAY);
>> +
>> + return act->change_context(irq, act->dev_id, IRQ_CAN_THREAD) == 0;
>
> This IRQ_CAN_THREAD just looks out of place of the other two. It feels
> very "hacky" to check if it can thread. But what do I know?
The problem is that the step to make a handler be threaded has to be split
in two: First ask, then remove IRQ_NODELAY, then change the locks to
mutexes. So the driver need to be involved twice. I could skip this, but I
put it in for generallity.
>
>> +}
>> +
>> +
>> +static int __make_irq_threaded(int irq, struct irq_desc *desc)
>> +{
>> + struct irqaction *act;
>> +
>> + for(act = desc->action; act; act = act->next) {
>> + WARN_ON(((~act->flags) & (SA_MUST_THREAD|SA_NODELAY)) == 0);
>> + if(!action_may_thread(irq, act)) {
>> + return -EINVAL;
>> + }
>> + }
>> +
>> + if (start_irq_thread(irq, desc))
>> + return -ENOMEM;
>
> I know that currently start_irq_thread can only return -ENOMEM on
> failure, but it may be more robust to capture the return code and return
> that anyway.
*nod*
This was copied from the original code, so the same thing is elsewher,
too.
>
>> +
>> + spin_lock_irq(&desc->lock);
>> + desc->status &= ~IRQ_NODELAY;
>> + spin_unlock_irq(&desc->lock);
>> +
>> + /* We can't make irq handlers change their context before we
>> + are sure no CPU is running them in hard irq context */
>> + synchronize_irq(irq);
>> +
>> + for(act = desc->action; act; act = act->next) {
>> + WARN_ON(((~act->flags) & (SA_MUST_THREAD|SA_NODELAY)) == 0);
>> + if(act->change_context) {
>> + /* This callback can't fail */
>
> Will all device drivers know that the callback can't fail?
Well, it is in the documentation.
>
>> + act->change_context(irq, act->dev_id, IRQ_TO_THREADED);
>> + spin_lock_irq(&desc->lock);
>> + act->flags &=~SA_NODELAY;
>> + act->flags |= SA_MUST_THREAD;
>> + spin_unlock_irq(&desc->lock);
>> + }
>> + }
>> +
>> + return 0;
>> +}
>
> [snipped the rest]
>
> -- Steve
>
>
^ permalink raw reply
* Re: [patch 3/5] [PREEMPT_RT] Changing interrupt handlers from running in thread to hardirq and back runtime.
From: Esben Nielsen @ 2006-06-04 17:34 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Esben Nielsen, linux-kernel, Ingo Molnar
In-Reply-To: <1149367140.13993.119.camel@localhost.localdomain>
On Sat, 3 Jun 2006, Steven Rostedt wrote:
> On Fri, 2006-06-02 at 23:23 +0100, Esben Nielsen wrote:
>> Makes it possible for the e100 ethernet driver to have it's interrupt handler
>> in both hard-irq and threaded context under PREEMPT_RT.
>>
>> Index: linux-2.6.16-rt23.spin_mutex/drivers/net/e100.c
>> ===================================================================
>> --- linux-2.6.16-rt23.spin_mutex.orig/drivers/net/e100.c
>> +++ linux-2.6.16-rt23.spin_mutex/drivers/net/e100.c
>> @@ -530,7 +530,7 @@ struct nic {
>> enum ru_state ru_running;
>>
>> spinlock_t cb_lock ____cacheline_aligned;
>> - spinlock_t cmd_lock;
>> + spin_mutex_t cmd_lock;
>> struct csr __iomem *csr;
>> enum scb_cmd_lo cuc_cmd;
>> unsigned int cbs_avail;
>> @@ -1950,6 +1950,30 @@ static int e100_rx_alloc_list(struct nic
>> return 0;
>> }
>>
>> +static int e100_change_context(int irq, void *dev_id,
>> + enum change_context_cmd cmd)
>> +{
>> + struct net_device *netdev = dev_id;
>> + struct nic *nic = netdev_priv(netdev);
>> +
>> + switch(cmd)
>> + {
>> + case IRQ_TO_HARDIRQ:
>> + if(!spin_mutexes_can_spin())
>> + return -ENOSYS;
>> +
>> + spin_mutex_to_spin(&nic->cmd_lock);
>> + break;
>> + case IRQ_CAN_THREAD:
>> + /* Ok - return 0 */
>> + break;
>
> Why even bother with the IRQ_CAN_THREAD. If this would be anything
> other than OK, then we shouldn't be using that request_irq2 (yuck!) call
> in the first place.
>
Just for the sake of generality. Nothing else. It would be very unlikely,
as you say, that it wouldn't return 0.
> -- Steve
Esben
^ permalink raw reply
* Re: [PATCH] Prevent au1xmmc.c breakage on non-Au1200 Alchemy
From: Russell King @ 2006-06-04 16:41 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-kernel, Andrew Morton
In-Reply-To: <20060603231827.GA2788@linux-mips.org>
On Sun, Jun 04, 2006 at 12:18:28AM +0100, Ralf Baechle wrote:
> The driver is selectable on other than Au1200 Alchemy systems but won't
> build nor work - there is no MMC hw.
Applied, thanks.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* Adaptec 7902 driver. Possible NMI watchdog lockup; linux-2.6.16.19
From: Marc D Ronell @ 2006-06-04 2:11 UTC (permalink / raw)
To: linux-scsi
Hi,
Apologies in advance if this is the wrong group to post this issue. I
think the following is an Adaptec 7902 driver problem.
I am testing the 2.6.16.19 linux kernel on a Tyan 2882 motherboard.
Its running with a pair of Opteron 250 processors. When I try to boot
with the kernel, it seems to fail on the scsi driver. A console log
of the errors is attached below.
Thanks for any help and suggestions,
Marc
Coda Kernel/Venus communications, v5.3.20, coda@cs.cmu.edu
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
NTFS driver 2.1.26 [Flags: R/O].
fuse init (API version 7.6)
JFS: nTxBlock = 8192, nTxLock = 65536
SGI XFS with large block/inode numbers, no debug enabled
Initializing Cryptographic API
io scheduler noop registered
io scheduler deadline registered (default)
io scheduler cfq registered
PCI: MSI quirk detected. pci_msi_quirk set.
PCI: MSI quirk detected. pci_msi_quirk set.
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
fakephp: Fake PCI Hot Plug Controller Driver
acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
acpiphp_ibm: ibm_find_acpi_device: Failed to get device information<3>acpiphp_ibm: ibm_find_ad
cpcihp_generic: Generic port I/O CompactPCI Hot Plug Driver version: 0.1
cpcihp_generic: not configured, disabling.
pciehp: PCI Express Hot Plug Controller Driver version: 0.4
ACPI: Power Button (FF) [PWRF]
ACPI: Power Button (CM) [PWRB]
ACPI: Processor [CPU1] (supports 8 throttling states)
lp: driver loaded but no devices found
Real Time Clock Driver v1.12ac
hpet_acpi_add: no address or irqs in _CRS
Non-volatile memory driver v1.2
hw_random: AMD768 system management I/O registers at 0x1000.
hw_random hardware driver 1.0.0 loaded
ppdev: user-space parallel port driver
Linux agpgart interface v0.101 (c) Dave Jones
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
GSI 16 sharing vector 0xA9 and IRQ 16
ACPI: PCI Interrupt 0000:02:02.0[A] -> GSI 26 (level, low) -> IRQ 169
0000:02:02.0: ttyS2 at I/O 0x8800 (irq = 169) is a 16550A
parport0: PC-style at 0x378 [PCSPP]
lp0: using parport0 (polling).
lp0: console ready
isa bounce pool size: 16 pages
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
nbd: registered device at major 43
Intel(R) PRO/1000 Network Driver - version 6.3.9-k4
Copyright (c) 1999-2005 Intel Corporation.
Ethernet Channel Bonding Driver: v3.0.1 (January 9, 2006)
bonding: Warning: either miimon or arp_interval and arp_ip_target module parameters must be sp.
pcnet32.c:v1.31c 01.Nov.2005 tsbogend@alpha.franken.de
e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
GSI 17 sharing vector 0xB1 and IRQ 17
ACPI: PCI Interrupt 0000:03:08.0[A] -> GSI 18 (level, low) -> IRQ 177
e100: eth0: e100_probe: addr 0xfeafb000, irq 177, MAC addr 00:E0:81:2A:59:7F
tg3.c:v3.49 (Feb 2, 2006)
GSI 18 sharing vector 0xB9 and IRQ 18
ACPI: PCI Interrupt 0000:02:09.0[A] -> GSI 24 (level, low) -> IRQ 185
eth1: Tigon3 [partno(BCM95704A7) rev 2003 PHY(5704)] (PCI:33MHz:64-bit) 10/100/1000BaseT Ether2
eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1]
eth1: dma_rwctrl[763f0000] dma_mask[64-bit]
GSI 19 sharing vector 0xC1 and IRQ 19
ACPI: PCI Interrupt 0000:02:09.1[B] -> GSI 25 (level, low) -> IRQ 193
eth2: Tigon3 [partno(BCM95704A7) rev 2003 PHY(5704)] (PCI:33MHz:64-bit) 10/100/1000BaseT Ether3
eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1]
eth2: dma_rwctrl[763f0000] dma_mask[64-bit]
forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.49.
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
PPP BSD Compression module registered
NET: Registered protocol family 24
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
netconsole: not configured, aborting
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
AMD8111: IDE controller at PCI slot 0000:00:07.1
AMD8111: chipset revision 3
AMD8111: not 100% native mode: will probe irqs later
AMD8111: 0000:00:07.1 (rev 03) UDMA133 controller
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
hda: PIONEER DVD-RW DVR-107D, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: SONY DVD RW DRU-800A, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: ATAPI 40X DVD-ROM DVD-R CD-R/RW drive, 2000kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
hdc: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33)
ACPI: PCI Interrupt 0000:02:06.0[A] -> GSI 24 (level, low) -> IRQ 185
scsi0 : Adaptec AIC79XX PCI-X SCSI HBA DRIVER, Rev 3.0
<Adaptec AIC7902 Ultra320 SCSI adapter>
aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI 33 or 66Mhz, 512 SCBs
Vendor: IBM Model: IC35L073UWDY10-0 Rev: S27Q
Type: Direct-Access ANSI SCSI revision: 03
target0:0:3: asynchronous
scsi0:A:3:0: Tagged Queuing enabled. Depth 32
target0:0:3: Beginning Domain Validation
target0:0:3: wide asynchronous
target0:0:3: FAST-160 WIDE SCSI 320.0 MB/s DT IU QAS RDSTRM RTI WRFLOW PCOMP (6.25 ns, offset)
0:0:3:0: Attempting to queue an ABORT message:CDB: 0x12 0x0 0x0 0x0 0xa4 0x0
scsi0: At time of recovery, card was not paused
>>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<<
scsi0: Dumping Card State at program address 0x26 Mode 0x33
Card was paused
INTSTAT[0x0] SELOID[0x3] SELID[0x0] HS_MAILBOX[0x0]
INTCTL[0x80]:(SWTMINTMASK) SEQINTSTAT[0x0] SAVED_MODE[0x11]
DFFSTAT[0x33]:(CURRFIFO_NONE|FIFO0FREE|FIFO1FREE)
SCSISIGI[0x25]:(P_DATAOUT_DT|ACKI|BSYI) SCSIPHASE[0x1]:(DATA_OUT_PHASE)
SCSIBUS[0x0] LASTPHASE[0x1]:(P_DATAOUT|P_BUSFREE)
SCSISEQ0[0x0] SCSISEQ1[0x12]:(ENAUTOATNP|ENRSELI)
SEQCTL0[0x0] SEQINTCTL[0x0] SEQ_FLAGS[0x0] SEQ_FLAGS2[0x4]:(SELECTOUT_QFROZEN)
QFREEZE_COUNT[0x0] KERNEL_QFREEZE_COUNT[0x0] MK_MESSAGE_SCB[0xff00]
MK_MESSAGE_SCSIID[0xff] SSTAT0[0x0] SSTAT1[0x11]:(REQINIT|PHASEMIS)
SSTAT2[0x0] SSTAT3[0x0] PERRDIAG[0xc0]:(HIPERR|HIZERO)
SIMODE1[0xa4]:(ENSCSIPERR|ENSCSIRST|ENSELTIMO)
LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x80]:(PACKETIZED)
LQOSTAT0[0x0] LQOSTAT1[0x0] LQOSTAT2[0xe1]:(LQOSTOP0|LQOPKT)
SCB Count = 4 CMDS_PENDING = 1 LASTSCB 0xffff CURRSCB 0x3 NEXTSCB 0xff00
qinstart = 14 qinfifonext = 14
QINFIFO:
WAITING_TID_QUEUES:
Pending list:
3 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x37]
Total 1
Kernel Free SCB list: 2 1 0
Sequencer Complete DMA-inprog list:
Sequencer Complete list:
Sequencer DMA-Up and Complete list:
Sequencer On QFreeze and Complete list:
scsi0: FIFO0 Free, LONGJMP == 0x80ff, SCB 0x0
SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS)
SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL)
SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0]
SOFFCNT[0x2] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0
HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL)
scsi0: FIFO1 Free, LONGJMP == 0x801b, SCB 0x3
SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS)
SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL)
SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0]
SOFFCNT[0x2] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0
HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL)
LQIN: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
scsi0: LQISTATE = 0x1, LQOSTATE = 0x0, OPTIONMODE = 0x52
scsi0: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x1
scsi0: SAVED_SCSIID = 0x0 SAVED_LUN = 0x0
SIMODE0[0xc]:(ENOVERRUN|ENIOERR)
CCSCBCTL[0x4]:(CCSCBDIR)
scsi0: REG0 == 0xff00, SINDEX = 0x108, DINDEX = 0x108
scsi0: SCBPTR == 0x3, SCB_NEXT == 0xff00, SCB_NEXT2 == 0xffcf
CDB 12 0 0 0 a4 0
STACK: 0x22 0x0 0x0 0x0 0x0 0x0 0x0 0x0
<<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>>
0:0:3:0: BDR message in message buffer
scsi0: Recovery code sleeping
scsi0: Recovery code awake
scsi0: Timer Expired (active 1)
aic79xx_abort returns 0x2003
0:0:3:0: Attempting to queue a TARGET RESET message:CDB: 0x12 0x0 0x0 0x0 0xa4 0x0
aic79xx_dev_reset returns 0x2003
Recovery SCB completes
NMI Watchdog detected LOCKUP on CPU 0
CPU 0
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.16.16 #2
RIP: 0010:[<ffffffff8060acfd>] <ffffffff8060acfd>{.text.lock.spinlock+22}
RSP: 0000:ffffffff808873d8 EFLAGS: 00000082
RAX: ffffffff8093bfd8 RBX: ffff81007fcf0000 RCX: ffff81007fcf3178
RDX: ffffffff80887408 RSI: ffff810002c11938 RDI: ffff81007f967f80
RBP: 0000000000000040 R08: 000000000000007f R09: 0000000000000100
R10: ffff810002c10cc0 R11: 000000000000007f R12: ffffffff80429a50
R13: ffffffff80887408 R14: 000000000000000a R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffffffff8092e000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
.8cF`;s;ì.ì..0 :°:ë..xêr0000ü(cFw|p°x(2sks;è.|ñ`````````````à..ñ`.Ø.cFw|.°x..ñp¬.¬æ;è.|ña`````)
Linux version 2.6.16.18 (root@corps) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #1 SMP Mon May 296
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000fbff0000 (usable)
BIOS-e820: 00000000fbff0000 - 00000000fbfff000 (ACPI data)
BIOS-e820: 00000000fbfff000 - 00000000fc000000 (ACPI NVS)
BIOS-e820: 00000000ff780000 - 0000000100000000 (reserved)
SRAT: PXM 0 -> APIC 0 -> Node 0
SRAT: PXM 1 -> APIC 1 -> Node 1
SRAT: Node 0 PXM 0 100000-80000000
SRAT: Node 1 PXM 1 80000000-fc000000
SRAT: Node 1 PXM 1 80000000-100000000
SRAT: Node 0 PXM 0 0-80000000
Bootmem setup node 0 0000000000000000-0000000080000000
Bootmem setup node 1 0000000080000000-00000000fbff0000
ACPI: PM-Timer IO Port: 0x1008
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:5 APIC version 16
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 15:5 APIC version 16
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled)
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23
ACPI: IOAPIC (id[0x03] address[0xfebff000] gsi_base[24])
IOAPIC[1]: apic_id 3, version 17, address 0xfebff000, GSI 24-27
ACPI: IOAPIC (id[0x04] address[0xfebfe000] gsi_base[28])
IOAPIC[2]: apic_id 4, version 17, address 0xfebfe000, GSI 28-31
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
Setting APIC routing to flat
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at fc400000 (gap: fc000000:3780000)
Checking aperture...
CPU 0: aperture @ 0 size 32 MB
No AGP bridge found
Built 2 zonelists
Kernel command line: root=/dev/md0 ro console=ttyS0,38400n8 console=tts/0,38400n8 console=tty0
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 131072 bytes)
Disabling vsyscall due to use of PM timer
time.c: Using 3.579545 MHz WALL PM GTOD PM timer.
time.c: Detected 2388.714 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Memory: 4056604k/4128704k available (5185k kernel code, 71712k reserved, 2507k data, 280k init)
Calibrating delay using timer specific routine.. 4789.09 BogoMIPS (lpj=9578182)
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 0(1) -> Node 0 -> Core 0
Using local APIC timer interrupts.
result 12441231
Detected 12.441 MHz APIC timer.
Booting processor 1/2 APIC 0x1
Initializing CPU#1
Calibrating delay using timer specific routine.. 4777.66 BogoMIPS (lpj=9555335)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 1(1) -> Node 1 -> Core 0
AMD Opteron(tm) Processor 250 stepping 0a
CPU 1: Syncing TSC to CPU 0.
CPU 1: synchronized TSC with CPU 0 (last diff -2 cycles, maxerr 901 cycles)
Brought up 2 CPUs
testing NMI watchdog ... OK.
migration_cost=776
DMI 2.3 present.
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using configuration type 1
ACPI: Subsystem revision 20060127
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
PCI-DMA: Disabling IOMMU.
PCI: Bridge: 0000:00:06.0
IO window: 9000-bfff
MEM window: fc900000-feafffff
PREFETCH window: disabled.
PCI: Bridge: 0000:00:0a.0
IO window: 7000-8fff
MEM window: fc600000-fc8fffff
PREFETCH window: ff500000-ff5fffff
PCI: Bridge: 0000:00:0b.0
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
IA32 emulation $Id: sys_ia32.c,v 1.32 2002/03/24 13:02:28 ak Exp $
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
Coda Kernel/Venus communications, v5.3.20, coda@cs.cmu.edu
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
NTFS driver 2.1.26 [Flags: R/O].
fuse init (API version 7.6)
JFS: nTxBlock = 8192, nTxLock = 65536
SGI XFS with large block/inode numbers, no debug enabled
Initializing Cryptographic API
io scheduler noop registered
io scheduler deadline registered (default)
io scheduler cfq registered
PCI: MSI quirk detected. pci_msi_quirk set.
PCI: MSI quirk detected. pci_msi_quirk set.
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
fakephp: Fake PCI Hot Plug Controller Driver
acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
acpiphp_ibm: ibm_find_acpi_device: Failed to get device information<3>acpiphp_ibm: ibm_find_ad
cpcihp_generic: Generic port I/O CompactPCI Hot Plug Driver version: 0.1
cpcihp_generic: not configured, disabling.
pciehp: PCI Express Hot Plug Controller Driver version: 0.4
ACPI: Power Button (FF) [PWRF]
ACPI: Power Button (CM) [PWRB]
ACPI: Processor [CPU1] (supports 8 throttling states)
lp: driver loaded but no devices found
Real Time Clock Driver v1.12ac
hpet_acpi_add: no address or irqs in _CRS
Non-volatile memory driver v1.2
hw_random: AMD768 system management I/O registers at 0x1000.
hw_random hardware driver 1.0.0 loaded
ppdev: user-space parallel port driver
Linux agpgart interface v0.101 (c) Dave Jones
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
GSI 16 sharing vector 0xA9 and IRQ 16
ACPI: PCI Interrupt 0000:02:02.0[A] -> GSI 26 (level, low) -> IRQ 169
0000:02:02.0: ttyS2 at I/O 0x8800 (irq = 169) is a 16550A
parport0: PC-style at 0x378 [PCSPP]
lp0: using parport0 (polling).
lp0: console ready
isa bounce pool size: 16 pages
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
nbd: registered device at major 43
Intel(R) PRO/1000 Network Driver - version 6.3.9-k4
Copyright (c) 1999-2005 Intel Corporation.
Ethernet Channel Bonding Driver: v3.0.1 (January 9, 2006)
bonding: Warning: either miimon or arp_interval and arp_ip_target module parameters must be sp.
pcnet32.c:v1.31c 01.Nov.2005 tsbogend@alpha.franken.de
e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
GSI 17 sharing vector 0xB1 and IRQ 17
ACPI: PCI Interrupt 0000:03:08.0[A] -> GSI 18 (level, low) -> IRQ 177
e100: eth0: e100_probe: addr 0xfeafb000, irq 177, MAC addr 00:E0:81:2A:59:7F
tg3.c:v3.49 (Feb 2, 2006)
GSI 18 sharing vector 0xB9 and IRQ 18
ACPI: PCI Interrupt 0000:02:09.0[A] -> GSI 24 (level, low) -> IRQ 185
eth1: Tigon3 [partno(BCM95704A7) rev 2003 PHY(5704)] (PCI:33MHz:64-bit) 10/100/1000BaseT Ether2
eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1]
eth1: dma_rwctrl[763f0000] dma_mask[64-bit]
GSI 19 sharing vector 0xC1 and IRQ 19
ACPI: PCI Interrupt 0000:02:09.1[B] -> GSI 25 (level, low) -> IRQ 193
eth2: Tigon3 [partno(BCM95704A7) rev 2003 PHY(5704)] (PCI:33MHz:64-bit) 10/100/1000BaseT Ether3
eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1]
eth2: dma_rwctrl[763f0000] dma_mask[64-bit]
forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.49.
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
PPP BSD Compression module registered
NET: Registered protocol family 24
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
netconsole: not configured, aborting
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
AMD8111: IDE controller at PCI slot 0000:00:07.1
AMD8111: chipset revision 3
AMD8111: not 100% native mode: will probe irqs later
AMD8111: 0000:00:07.1 (rev 03) UDMA133 controller
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
hda: PIONEER DVD-RW DVR-107D, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: SONY DVD RW DRU-800A, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: ATAPI 40X DVD-ROM DVD-R CD-R/RW drive, 2000kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
hdc: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33)
ACPI: PCI Interrupt 0000:02:06.0[A] -> GSI 24 (level, low) -> IRQ 185
scsi0 : Adaptec AIC79XX PCI-X SCSI HBA DRIVER, Rev 3.0
<Adaptec AIC7902 Ultra320 SCSI adapter>
aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI 33 or 66Mhz, 512 SCBs
Vendor: IBM Model: IC35L073UWDY10-0 Rev: S27Q
Type: Direct-Access ANSI SCSI revision: 03
target0:0:3: asynchronous
scsi0:A:3:0: Tagged Queuing enabled. Depth 32
target0:0:3: Beginning Domain Validation
target0:0:3: wide asynchronous
target0:0:3: FAST-160 WIDE SCSI 320.0 MB/s DT IU QAS RDSTRM RTI WRFLOW PCOMP (6.25 ns, offset)
0:0:3:0: Attempting to queue an ABORT message:CDB: 0x12 0x0 0x0 0x0 0xa4 0x0
scsi0: At time of recovery, card was not paused
>>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<<
scsi0: Dumping Card State at program address 0x2 Mode 0x22
Card was paused
INTSTAT[0x0] SELOID[0x3] SELID[0x0] HS_MAILBOX[0x0]
INTCTL[0x80]:(SWTMINTMASK) SEQINTSTAT[0x0] SAVED_MODE[0x11]
DFFSTAT[0x33]:(CURRFIFO_NONE|FIFO0FREE|FIFO1FREE)
SCSISIGI[0x25]:(P_DATAOUT_DT|ACKI|BSYI) SCSIPHASE[0x1]:(DATA_OUT_PHASE)
SCSIBUS[0x0] LASTPHASE[0x1]:(P_DATAOUT|P_BUSFREE)
SCSISEQ0[0x0] SCSISEQ1[0x12]:(ENAUTOATNP|ENRSELI)
SEQCTL0[0x0] SEQINTCTL[0x0] SEQ_FLAGS[0x0] SEQ_FLAGS2[0x4]:(SELECTOUT_QFROZEN)
QFREEZE_COUNT[0x0] KERNEL_QFREEZE_COUNT[0x0] MK_MESSAGE_SCB[0xff00]
MK_MESSAGE_SCSIID[0xff] SSTAT0[0x0] SSTAT1[0x11]:(REQINIT|PHASEMIS)
SSTAT2[0x0] SSTAT3[0x0] PERRDIAG[0xc0]:(HIPERR|HIZERO)
SIMODE1[0xa4]:(ENSCSIPERR|ENSCSIRST|ENSELTIMO)
LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x80]:(PACKETIZED)
LQOSTAT0[0x0] LQOSTAT1[0x0] LQOSTAT2[0xe1]:(LQOSTOP0|LQOPKT)
SCB Count = 4 CMDS_PENDING = 1 LASTSCB 0xffff CURRSCB 0x3 NEXTSCB 0xff00
qinstart = 14 qinfifonext = 14
QINFIFO:
WAITING_TID_QUEUES:
Pending list:
3 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x37]
Total 1
Kernel Free SCB list: 2 1 0
Sequencer Complete DMA-inprog list:
Sequencer Complete list:
Sequencer DMA-Up and Complete list:
Sequencer On QFreeze and Complete list:
scsi0: FIFO0 Free, LONGJMP == 0x80ff, SCB 0x0
SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS)
SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL)
SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0]
SOFFCNT[0x2] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0
HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL)
scsi0: FIFO1 Free, LONGJMP == 0x801b, SCB 0x3
SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS)
SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL)
SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0]
SOFFCNT[0x2] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0
HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL)
LQIN: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
scsi0: LQISTATE = 0x1, LQOSTATE = 0x0, OPTIONMODE = 0x52
scsi0: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x1
scsi0: SAVED_SCSIID = 0x0 SAVED_LUN = 0x0
SIMODE0[0xc]:(ENOVERRUN|ENIOERR)
CCSCBCTL[0x4]:(CCSCBDIR)
scsi0: REG0 == 0x3, SINDEX = 0x108, DINDEX = 0x108
scsi0: SCBPTR == 0xff03, SCB_NEXT == 0xff00, SCB_NEXT2 == 0x0
CDB 3 1 0 0 0 0
STACK: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
<<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>>
0:0:3:0: BDR message in message buffer
scsi0: Recovery code sleeping
scsi0: Recovery code awake
scsi0: Timer Expired (active 1)
aic79xx_abort returns 0x2003
0:0:3:0: Attempting to queue a TARGET RESET message:CDB: 0x12 0x0 0x0 0x0 0xa4 0x0
aic79xx_dev_reset returns 0x2003
Recovery SCB completes
NMI Watchdog detected LOCKUP on CPU 0
CPU 0
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.16.18 #1
RIP: 0010:[<ffffffff8060ae3d>] <ffffffff8060ae3d>{.text.lock.spinlock+22}
RSP: 0000:ffffffff808875d8 EFLAGS: 00000082
RAX: ffffffff8093bfd8 RBX: ffff81007fcf0000 RCX: ffff81007fcf3178
RDX: ffffffff80887608 RSI: ffff810002c11b88 RDI: ffff81007f90db00
RBP: 0000000000000040 R08: 0000000000000002 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000001 R12: ffffffff80429b90
R13: ffffffff80887608 R14: 000000000000000a R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffffffff8092e000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000000101000 CR4: 00000000000006e0
Process swapper (pid: 0, threadinfo ffffffff8093a000, task ffffffff8073a180)
Stack: 0000000000000296 ffffffff80429bac 0000000000000100 ffff810002c10e00
ffffffff80429b90 ffffffff8013adb3 ffffffff80887608 ffffffff80887608
.(cFq..°x(2sks;h.|ña``````````` à.8ñ`dØ(cFw|.°x(2sks;è.|ñ`````````````à..ñ`.Ø.cFw|.°x..ñp,.¬æ;)
Linux version 2.6.16.19 (root@corps) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #1 SMP Sat Jun 3 6
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000fbff0000 (usable)
BIOS-e820: 00000000fbff0000 - 00000000fbfff000 (ACPI data)
BIOS-e820: 00000000fbfff000 - 00000000fc000000 (ACPI NVS)
BIOS-e820: 00000000ff780000 - 0000000100000000 (reserved)
SRAT: PXM 0 -> APIC 0 -> Node 0
SRAT: PXM 1 -> APIC 1 -> Node 1
SRAT: Node 0 PXM 0 100000-80000000
SRAT: Node 1 PXM 1 80000000-fc000000
SRAT: Node 1 PXM 1 80000000-100000000
SRAT: Node 0 PXM 0 0-80000000
Bootmem setup node 0 0000000000000000-0000000080000000
Bootmem setup node 1 0000000080000000-00000000fbff0000
ACPI: PM-Timer IO Port: 0x1008
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:5 APIC version 16
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 15:5 APIC version 16
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled)
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23
ACPI: IOAPIC (id[0x03] address[0xfebff000] gsi_base[24])
IOAPIC[1]: apic_id 3, version 17, address 0xfebff000, GSI 24-27
ACPI: IOAPIC (id[0x04] address[0xfebfe000] gsi_base[28])
IOAPIC[2]: apic_id 4, version 17, address 0xfebfe000, GSI 28-31
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
Setting APIC routing to physical flat
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at fc400000 (gap: fc000000:3780000)
Checking aperture...
CPU 0: aperture @ 0 size 32 MB
No AGP bridge found
SMP: Allowing 4 CPUs, 2 hotplug CPUs
Built 2 zonelists
Kernel command line: root=/dev/md0 ro console=ttyS0,38400n8 console=tts/0,38400n8 console=tty0
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 131072 bytes)
Disabling vsyscall due to use of PM timer
time.c: Using 3.579545 MHz WALL PM GTOD PM timer.
time.c: Detected 2387.448 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Memory: 4059464k/4128704k available (3133k kernel code, 68852k reserved, 1797k data, 204k init)
Calibrating delay using timer specific routine.. 4786.35 BogoMIPS (lpj=9572707)
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 0(1) -> Node 0 -> Core 0
Using local APIC timer interrupts.
result 12434638
Detected 12.434 MHz APIC timer.
Booting processor 1/2 APIC 0x1
Initializing CPU#1
Calibrating delay using timer specific routine.. 4775.13 BogoMIPS (lpj=9550265)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 1(1) -> Node 1 -> Core 0
AMD Opteron(tm) Processor 250 stepping 0a
CPU 1: Syncing TSC to CPU 0.
CPU 1: synchronized TSC with CPU 0 (last diff -1 cycles, maxerr 900 cycles)
Brought up 2 CPUs
testing NMI watchdog ... OK.
migration_cost=550
DMI 2.3 present.
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using configuration type 1
ACPI: Subsystem revision 20060127
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs<7>Losing some ticks... checking if CPU frequency changed.
3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
PCI-DMA: Disabling IOMMU.
PCI: Bridge: 0000:00:06.0
IO window: 9000-bfff
MEM window: fc900000-feafffff
PREFETCH window: disabled.
PCI: Bridge: 0000:00:0a.0
IO window: 7000-8fff
MEM window: fc600000-fc8fffff
PREFETCH window: ff500000-ff5fffff
PCI: Bridge: 0000:00:0b.0
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
IA32 emulation $Id: sys_ia32.c,v 1.32 2002/03/24 13:02:28 ak Exp $
Total HugeTLB memory allocated, 0
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
PCI: MSI quirk detected. pci_msi_quirk set.
PCI: MSI quirk detected. pci_msi_quirk set.
ACPI: Power Button (FF) [PWRF]
ACPI: Power Button (CM) [PWRB]
ACPI: Processor [CPU1] (supports 8 throttling states)
Real Time Clock Driver v1.12ac
hpet_acpi_add: no address or irqs in _CRS
hw_random: AMD768 system management I/O registers at 0x1000.
hw_random hardware driver 1.0.0 loaded
Software Watchdog Timer: 0.07 initialized. soft_noboot=0 soft_margin=60 sec (nowayout= 0)
Linux agpgart interface v0.101 (c) Dave Jones
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
GSI 16 sharing vector 0xA9 and IRQ 16
ACPI: PCI Interrupt 0000:02:02.0[A] -> GSI 26 (level, low) -> IRQ 169
0000:02:02.0: ttyS2 at I/O 0x8800 (irq = 169) is a 16550A
isa bounce pool size: 16 pages
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
Intel(R) PRO/1000 Network Driver - version 6.3.9-k4
Copyright (c) 1999-2005 Intel Corporation.
e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
GSI 17 sharing vector 0xB1 and IRQ 17
ACPI: PCI Interrupt 0000:03:08.0[A] -> GSI 18 (level, low) -> IRQ 177
e100: eth0: e100_probe: addr 0xfeafb000, irq 177, MAC addr 00:E0:81:2A:59:7F
tg3.c:v3.49 (Feb 2, 2006)
GSI 18 sharing vector 0xB9 and IRQ 18
ACPI: PCI Interrupt 0000:02:09.0[A] -> GSI 24 (level, low) -> IRQ 185
eth1: Tigon3 [partno(BCM95704A7) rev 2003 PHY(5704)] (PCI:33MHz:64-bit) 10/100/1000BaseT Ether2
eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1]
eth1: dma_rwctrl[763f0000] dma_mask[64-bit]
GSI 19 sharing vector 0xC1 and IRQ 19
ACPI: PCI Interrupt 0000:02:09.1[B] -> GSI 25 (level, low) -> IRQ 193
eth2: Tigon3 [partno(BCM95704A7) rev 2003 PHY(5704)] (PCI:33MHz:64-bit) 10/100/1000BaseT Ether3
eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1]
eth2: dma_rwctrl[763f0000] dma_mask[64-bit]
forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.49.
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
netconsole: not configured, aborting
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
AMD8111: IDE controller at PCI slot 0000:00:07.1
AMD8111: chipset revision 3
AMD8111: not 100% native mode: will probe irqs later
AMD8111: 0000:00:07.1 (rev 03) UDMA133 controller
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
hda: PIONEER DVD-RW DVR-107D, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: SONY DVD RW DRU-800A, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: ATAPI 40X DVD-ROM DVD-R CD-R/RW drive, 2000kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
hdc: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33)
ACPI: PCI Interrupt 0000:02:06.0[A] -> GSI 24 (level, low) -> IRQ 185
scsi0 : Adaptec AIC79XX PCI-X SCSI HBA DRIVER, Rev 3.0
<Adaptec AIC7902 Ultra320 SCSI adapter>
aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI 33 or 66Mhz, 512 SCBs
Vendor: IBM Model: IC35L073UWDY10-0 Rev: S27Q
Type: Direct-Access ANSI SCSI revision: 03
target0:0:3: asynchronous
scsi0:A:3:0: Tagged Queuing enabled. Depth 32
target0:0:3: Beginning Domain Validation
target0:0:3: wide asynchronous
target0:0:3: FAST-160 WIDE SCSI 320.0 MB/s DT IU QAS RDSTRM RTI WRFLOW PCOMP (6.25 ns, offset)
0:0:3:0: Attempting to queue an ABORT message:CDB: 0x12 0x0 0x0 0x0 0xa4 0x0
scsi0: At time of recovery, card was not paused
>>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<<
scsi0: Dumping Card State at program address 0x5 Mode 0x33
Card was paused
INTSTAT[0x0] SELOID[0x3] SELID[0x0] HS_MAILBOX[0x0]
INTCTL[0x80] SEQINTSTAT[0x0] SAVED_MODE[0x11] DFFSTAT[0x33]
SCSISIGI[0x24] SCSIPHASE[0x1] SCSIBUS[0x0] LASTPHASE[0x1]
SCSISEQ0[0x0] SCSISEQ1[0x12] SEQCTL0[0x0] SEQINTCTL[0x0]
SEQ_FLAGS[0x0] SEQ_FLAGS2[0x4] QFREEZE_COUNT[0x0]
KERNEL_QFREEZE_COUNT[0x0] MK_MESSAGE_SCB[0xff00]
MK_MESSAGE_SCSIID[0xff] SSTAT0[0x0] SSTAT1[0x11]
SSTAT2[0x0] SSTAT3[0x0] PERRDIAG[0xc0] SIMODE1[0xa4]
LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x80] LQOSTAT0[0x0]
LQOSTAT1[0x0] LQOSTAT2[0xe1]
SCB Count = 4 CMDS_PENDING = 1 LASTSCB 0xffff CURRSCB 0x3 NEXTSCB 0xff00
qinstart = 14 qinfifonext = 14
QINFIFO:
WAITING_TID_QUEUES:
Pending list:
3 FIFO_USE[0x0] SCB_CONTROL[0x60] SCB_SCSIID[0x37]
Total 1
Kernel Free SCB list: 2 1 0
Sequencer Complete DMA-inprog list:
Sequencer Complete list:
Sequencer DMA-Up and Complete list:
Sequencer On QFreeze and Complete list:
scsi0: FIFO0 Free, LONGJMP == 0x80ff, SCB 0x0
SEQIMODE[0x3f] SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]
SG_CACHE_SHADOW[0x2] SG_STATE[0x0] DFFSXFRCTL[0x0]
SOFFCNT[0x2] MDFFSTAT[0x5] SHADDR = 0x00, SHCNT = 0x0
HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]
scsi0: FIFO1 Free, LONGJMP == 0x801b, SCB 0x3
SEQIMODE[0x3f] SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]
SG_CACHE_SHADOW[0x2] SG_STATE[0x0] DFFSXFRCTL[0x0]
SOFFCNT[0x2] MDFFSTAT[0x5] SHADDR = 0x00, SHCNT = 0x0
HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]
LQIN: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
scsi0: LQISTATE = 0x1, LQOSTATE = 0x0, OPTIONMODE = 0x52
scsi0: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x1
.(cFq..°xqqqqqqqqqqqqqqqqqqqqqqqqñØpsç0.cF``..0.0.Y0{òs3û..Çs :00000(cF``ú.úxp²;.ê.'.à82`...00)
Linux version 2.6.16.19 (root@corps) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #1 SMP Sat Jun 3 6
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000fbff0000 (usable)
BIOS-e820: 00000000fbff0000 - 00000000fbfff000 (ACPI data)
BIOS-e820: 00000000fbfff000 - 00000000fc000000 (ACPI NVS)
BIOS-e820: 00000000ff780000 - 0000000100000000 (reserved)
SRAT: PXM 0 -> APIC 0 -> Node 0
SRAT: PXM 1 -> APIC 1 -> Node 1
SRAT: Node 0 PXM 0 100000-80000000
SRAT: Node 1 PXM 1 80000000-fc000000
SRAT: Node 1 PXM 1 80000000-100000000
SRAT: Node 0 PXM 0 0-80000000
Bootmem setup node 0 0000000000000000-0000000080000000
Bootmem setup node 1 0000000080000000-00000000fbff0000
ACPI: PM-Timer IO Port: 0x1008
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:5 APIC version 16
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 15:5 APIC version 16
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled)
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23
ACPI: IOAPIC (id[0x03] address[0xfebff000] gsi_base[24])
IOAPIC[1]: apic_id 3, version 17, address 0xfebff000, GSI 24-27
ACPI: IOAPIC (id[0x04] address[0xfebfe000] gsi_base[28])
IOAPIC[2]: apic_id 4, version 17, address 0xfebfe000, GSI 28-31
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
Setting APIC routing to physical flat
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at fc400000 (gap: fc000000:3780000)
Checking aperture...
CPU 0: aperture @ 0 size 32 MB
No AGP bridge found
SMP: Allowing 4 CPUs, 2 hotplug CPUs
Built 2 zonelists
Kernel command line: root=/dev/md0 ro aic79xx=verbose,no_reset,debug:0xffff console=ttyS0,38400
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 131072 bytes)
Disabling vsyscall due to use of PM timer
time.c: Using 3.579545 MHz WALL PM GTOD PM timer.
time.c: Detected 2387.399 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Memory: 4059464k/4128704k available (3133k kernel code, 68852k reserved, 1797k data, 204k init)
Calibrating delay using timer specific routine.. 4786.32 BogoMIPS (lpj=9572657)
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 0(1) -> Node 0 -> Core 0
Using local APIC timer interrupts.
result 12434382
Detected 12.434 MHz APIC timer.
Booting processor 1/2 APIC 0x1
Initializing CPU#1
Calibrating delay using timer specific routine.. 4774.83 BogoMIPS (lpj=9549661)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 1(1) -> Node 1 -> Core 0
AMD Opteron(tm) Processor 250 stepping 0a
CPU 1: Syncing TSC to CPU 0.
CPU 1: synchronized TSC with CPU 0 (last diff -3 cycles, maxerr 900 cycles)
Brought up 2 CPUs
testing NMI watchdog ... OK.
migration_cost=548
DMI 2.3 present.
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using configuration type 1
ACPI: Subsystem revision 20060127
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs<7>Losing some ticks... checking if CPU frequency changed.
3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
PCI-DMA: Disabling IOMMU.
PCI: Bridge: 0000:00:06.0
IO window: 9000-bfff
MEM window: fc900000-feafffff
PREFETCH window: disabled.
PCI: Bridge: 0000:00:0a.0
IO window: 7000-8fff
MEM window: fc600000-fc8fffff
PREFETCH window: ff500000-ff5fffff
PCI: Bridge: 0000:00:0b.0
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
IA32 emulation $Id: sys_ia32.c,v 1.32 2002/03/24 13:02:28 ak Exp $
Total HugeTLB memory allocated, 0
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
PCI: MSI quirk detected. pci_msi_quirk set.
PCI: MSI quirk detected. pci_msi_quirk set.
ACPI: Power Button (FF) [PWRF]
ACPI: Power Button (CM) [PWRB]
ACPI: Processor [CPU1] (supports 8 throttling states)
Real Time Clock Driver v1.12ac
hpet_acpi_add: no address or irqs in _CRS
hw_random: AMD768 system management I/O registers at 0x1000.
hw_random hardware driver 1.0.0 loaded
Software Watchdog Timer: 0.07 initialized. soft_noboot=0 soft_margin=60 sec (nowayout= 0)
Linux agpgart interface v0.101 (c) Dave Jones
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
GSI 16 sharing vector 0xA9 and IRQ 16
ACPI: PCI Interrupt 0000:02:02.0[A] -> GSI 26 (level, low) -> IRQ 169
0000:02:02.0: ttyS2 at I/O 0x8800 (irq = 169) is a 16550A
isa bounce pool size: 16 pages
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
Intel(R) PRO/1000 Network Driver - version 6.3.9-k4
Copyright (c) 1999-2005 Intel Corporation.
e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
GSI 17 sharing vector 0xB1 and IRQ 17
ACPI: PCI Interrupt 0000:03:08.0[A] -> GSI 18 (level, low) -> IRQ 177
e100: eth0: e100_probe: addr 0xfeafb000, irq 177, MAC addr 00:E0:81:2A:59:7F
tg3.c:v3.49 (Feb 2, 2006)
GSI 18 sharing vector 0xB9 and IRQ 18
ACPI: PCI Interrupt 0000:02:09.0[A] -> GSI 24 (level, low) -> IRQ 185
eth1: Tigon3 [partno(BCM95704A7) rev 2003 PHY(5704)] (PCI:33MHz:64-bit) 10/100/1000BaseT Ether2
eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1]
eth1: dma_rwctrl[763f0000] dma_mask[64-bit]
GSI 19 sharing vector 0xC1 and IRQ 19
ACPI: PCI Interrupt 0000:02:09.1[B] -> GSI 25 (level, low) -> IRQ 193
eth2: Tigon3 [partno(BCM95704A7) rev 2003 PHY(5704)] (PCI:33MHz:64-bit) 10/100/1000BaseT Ether3
eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1]
eth2: dma_rwctrl[763f0000] dma_mask[64-bit]
forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.49.
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
netconsole: not configured, aborting
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
AMD8111: IDE controller at PCI slot 0000:00:07.1
AMD8111: chipset revision 3
AMD8111: not 100% native mode: will probe irqs later
AMD8111: 0000:00:07.1 (rev 03) UDMA133 controller
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
hda: PIONEER DVD-RW DVR-107D, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: SONY DVD RW DRU-800A, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: ATAPI 40X DVD-ROM DVD-R CD-R/RW drive, 2000kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
hdc: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33)
ACPI: PCI Interrupt 0000:02:06.0[A] -> GSI 24 (level, low) -> IRQ 185
ahd_pci:2:6:0: Enabling 39Bit Addressing
ahd_pci:2:6:0: Reading VPD from SEEPROM...ahd_pci:2:6:0: VPD parsing successful
ahd_pci:2:6:0: Reading SEEPROM...done.
ahd_pci:2:6:0: STPWLEVEL is on
ahd_pci:2:6:0: Manual Primary Termination
ahd_pci:2:6:0: Manual Secondary Termination
ahd_pci:2:6:0: Primary High byte termination Enabled
ahd_pci:2:6:0: Primary Low byte termination Enabled
ahd_pci:2:6:0: Secondary High byte termination Disabled
ahd_pci:2:6:0: Secondary Low byte termination Disabled
ahd_pci:2:6:0: Downloading Sequencer Program... 689 instructions downloaded
ahd_pci:2:6:0: Features 0x7c101, Bugs 0x700002, Flags 0x143f1
scsi0 : Adaptec AIC79XX PCI-X SCSI HBA DRIVER, Rev 3.0
<Adaptec AIC7902 Ultra320 SCSI adapter>
aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI 33 or 66Mhz, 512 SCBs
scsi0: Slave Alloc 0
target0:0:0: FAST-5 SCSI 1.0 MB/s ST (1020 ns, offset 255)
scsi0: target 0 using 8bit transfers
target0:0:0: asynchronous
scsi0: target 0 using asynchronous transfers
scsi0: Selection Timeout on A:0. 0 SCBs aborted
scsi0: Slave Destroy 0
scsi0: Slave Alloc 1
target0:0:1: FAST-5 SCSI 1.0 MB/s ST (1020 ns, offset 255)
scsi0: target 1 using 8bit transfers
target0:0:1: asynchronous
scsi0: target 1 using asynchronous transfers
scsi0: Selection Timeout on A:1. 0 SCBs aborted
scsi0: Slave Destroy 1
scsi0: Slave Alloc 2
target0:0:2: FAST-5 SCSI 1.0 MB/s ST (1020 ns, offset 255)
scsi0: target 2 using 8bit transfers
target0:0:2: asynchronous
scsi0: target 2 using asynchronous transfers
scsi0: Selection Timeout on A:2. 0 SCBs aborted
scsi0: Slave Destroy 2
scsi0: Slave Alloc 3
(scsi0:A:3:0): Sending WDTR 0
(scsi0:A:3:0): Received WDTR 0 filtered to 0
target0:0:3: FAST-5 SCSI 1.0 MB/s ST (1020 ns, offset 255)
scsi0: target 3 using 8bit transfers
(scsi0:A:3:0): Sending SDTR period 44, offset 0
(scsi0:A:3:0): Received SDTR period 44, offset 0
Filtered to period 0, offset 0
target0:0:3: asynchronous
scsi0: target 3 using asynchronous transfers
Vendor: IBM Model: IC35L073UWDY10-0 Rev: S27Q
Type: Direct-Access ANSI SCSI revision: 03
0:0:3:0: Slave Configure
target0:0:3: asynchronous
scsi0:A:3:0: Tagged Queuing enabled. Depth 32
target0:0:3: Beginning Domain Validation
(scsi0:A:3:0): Sending WDTR 1
(scsi0:A:3:0): Received WDTR 1 filtered to 1
target0:0:3: FAST-5 WIDE SCSI 2.0 MB/s ST (1020 ns, offset 255)
scsi0: target 3 using 16bit transfers
(scsi0:A:3:0): Sending SDTR period 44, offset 0
(scsi0:A:3:0): Received SDTR period 44, offset 0
Filtered to period 0, offset 0
target0:0:3: wide asynchronous
scsi0: target 3 using asynchronous transfers
(scsi0:A:3:0): Sending WDTR 1
(scsi0:A:3:0): Received WDTR 1 filtered to 1
target0:0:3: FAST-5 WIDE SCSI 2.0 MB/s ST (1020 ns, offset 255)
scsi0: target 3 using 16bit transfers
(scsi0:A:3:0): Sending SDTR period 44, offset 0
(scsi0:A:3:0): Received SDTR period 44, offset 0
Filtered to period 0, offset 0
target0:0:3: wide asynchronous
scsi0: target 3 using asynchronous transfers
(scsi0:A:3:0): Sending WDTR 1
(scsi0:A:3:0): Received WDTR 1 filtered to 1
target0:0:3: FAST-5 WIDE SCSI 2.0 MB/s ST (1020 ns, offset 255)
scsi0: target 3 using 16bit transfers
(scsi0:A:3:0): Sending SDTR period 44, offset 0
(scsi0:A:3:0): Received SDTR period 44, offset 0
Filtered to period 0, offset 0
target0:0:3: wide asynchronous
scsi0: target 3 using asynchronous transfers
(scsi0:A:3:0): Sending PPR bus_width 1, period 8, offset fe, ppr_options f7
(scsi0:A:3:0): Received PPR width 1, period 8, offset 7f,options f7
Filtered to width 1, period 8, offset 7f, options f7
target0:0:3: FAST-160 WIDE SCSI 320.0 MB/s DT IU QAS RDSTRM RTI WRFLOW PCOMP (6.25 ns, offset)
scsi0: target 3 synchronous with period = 0x8, offset = 0x7f(RDSTRM|DT|IU|RTI|QAS)
0:0:3:0: Attempting to queue an ABORT message:CDB: 0x12 0x0 0x0 0x0 0xa4 0x0
scsi0: At time of recovery, card was not paused
>>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<<
scsi0: Dumping Card State at program address 0x5 Mode 0x33
Card was paused
INTSTAT[0x0] SELOID[0x3] SELID[0x0] HS_MAILBOX[0x0]
INTCTL[0x80] SEQINTSTAT[0x0] SAVED_MODE[0x11] DFFSTAT[0x33]
SCSISIGI[0x24] SCSIPHASE[0x1] SCSIBUS[0x0] LASTPHASE[0x1]
SCSISEQ0[0x0] SCSISEQ1[0x12] SEQCTL0[0x0] SEQINTCTL[0x0]
SEQ_FLAGS[0x0] SEQ_FLAGS2[0x4] QFREEZE_COUNT[0x0]
KERNEL_QFREEZE_COUNT[0x0] MK_MESSAGE_SCB[0xff00]
MK_MESSAGE_SCSIID[0xff] SSTAT0[0x0] SSTAT1[0x11]
SSTAT2[0x0] SSTAT3[0x0] PERRDIAG[0xc0] SIMODE1[0xa4]
LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x80] LQOSTAT0[0x0]
LQOSTAT1[0x0] LQOSTAT2[0xe1]
SCB Count = 4 CMDS_PENDING = 1 LASTSCB 0xffff CURRSCB 0x3 NEXTSCB 0xff00
qinstart = 14 qinfifonext = 14
QINFIFO:
WAITING_TID_QUEUES:
Pending list:
3 FIFO_USE[0x0] SCB_CONTROL[0x60] SCB_SCSIID[0x37]
Total 1
Kernel Free SCB list: 2 1 0
Sequencer Complete DMA-inprog list:
Sequencer Complete list:
Sequencer DMA-Up and Complete list:
Sequencer On QFreeze and Complete list:
scsi0: FIFO0 Free, LONGJMP == 0x80ff, SCB 0x0
SEQIMODE[0x3f] SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]
SG_CACHE_SHADOW[0x2] SG_STATE[0x0] DFFSXFRCTL[0x0]
SOFFCNT[0x2] MDFFSTAT[0x5] SHADDR = 0x00, SHCNT = 0x0
HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]
scsi0: FIFO1 Free, LONGJMP == 0x801b, SCB 0x3
SEQIMODE[0x3f] SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]
SG_CACHE_SHADOW[0x2] SG_STATE[0x0] DFFSXFRCTL[0x0]
SOFFCNT[0x2] MDFFSTAT[0x5] SHADDR = 0x00, SHCNT = 0x0
HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]
LQIN: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
scsi0: LQISTATE = 0x1, LQOSTATE = 0x0, OPTIONMODE = 0x52
scsi0: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x1
scsi0: SAVED_SCSIID = 0x0 SAVED_LUN = 0x0
SIMODE0[0xc]
CCSCBCTL[0x4]
scsi0: REG0 == 0xff00, SINDEX = 0x108, DINDEX = 0x108
scsi0: SCBPTR == 0x3, SCB_NEXT == 0xff00, SCB_NEXT2 == 0xffe8
CDB 12 0 0 0 a4 0
STACK: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
<<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>>
0:0:3:0: BDR message in message buffer
scsi0: Recovery code sleeping
scsi0: Recovery code awake
scsi0: Timer Expired (active 1)
aic79xx_abort returns 0x2003
0:0:3:0: Attempting to queue a TARGET RESET message:CDB: 0x12 0x0 0x0 0x0 0xa4 0x0
aic79xx_dev_reset returns 0x2003
Recovery SCB completes
target0:0:3: FAST-160 SCSI 160.0 MB/s DT IU QAS RDSTRM RTI WRFLOW PCOMP (6.25 ns, offset 127)
scsi0: target 3 using 8bit transfers
target0:0:3: asynchronous
scsi0: target 3 using asynchronous transfers
scsi0: target 4 using 8bit transfers
scsi0: target 4 using asynchronous transfers
scsi0: target 5 using 8bit transfers
scsi0: target 5 using asynchronous transfers
scsi0: target 6 using 8bit transfers
scsi0: target 6 using asynchronous transfers
scsi0: target 7 using 8bit transfers
scsi0: target 7 using asynchronous transfers
scsi0: target 8 using 8bit transfers
scsi0: target 8 using asynchronous transfers
scsi0: target 9 using 8bit transfers
scsi0: target 9 using asynchronous transfers
scsi0: target 10 using 8bit transfers
scsi0: target 10 using asynchronous transfers
scsi0: target 11 using 8bit transfers
scsi0: target 11 using asynchronous transfers
scsi0: target 12 using 8bit transfers
scsi0: target 12 using asynchronous transfers
scsi0: target 13 using 8bit transfers
scsi0: target 13 using asynchronous transfers
scsi0: target 14 using 8bit transfers
scsi0: target 14 using asynchronous transfers
scsi0: target 15 using 8bit transfers
scsi0: target 15 using asynchronous transfers
NMI Watchdog detected LOCKUP on CPU 0
CPU 0
Modules linked in:
Pid: 857, comm: scsi_eh_0 Tainted: G M 2.6.16.19 #1
RIP: 0010:[<ffffffff8040a31d>] <ffffffff8040a31d>{.text.lock.spinlock+22}
RSP: 0000:ffff81007fd27d88 EFLAGS: 00000086
RAX: 00000000012143e1 RBX: ffff81007fcf8000 RCX: 0000000000000002
RDX: 33ff810002e26ff0 RSI: 0000000000000003 RDI: ffff81007fd9b300
RBP: ffff81007fcf8000 R08: 0000000000000003 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000010 R14: 0000000000000010 R15: 0000000000000001
FS: 0000000000000000(0000) GS:ffffffff8065e000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000000101000 CR4: 00000000000006e0
Process scsi_eh_0 (pid: 857, threadinfo ffff81007fd26000, task ffff810082194300)
Stack: 0000000000000087 ffffffff8030debd 00000000012143e1 ffff81007fcfb148
ffff81007fcf8000 ffffffff80305ace 0000000f00000007 0000000f02d28000
00000041ffffffff 0000000000000000
Call Trace: <ffffffff8030debd>{ahd_freeze_simq+22} <ffffffff80305ace>{ahd_reset_channel+990}
<ffffffff8030c0a4>{ahd_linux_bus_reset+68} <ffffffff802e9de3>{scsi_try_bus_reset+37}
<ffffffff802e9f37>{scsi_eh_bus_reset+95} <ffffffff8014498f>{keventd_create_kthread+0}
<ffffffff802ea342>{scsi_eh_ready_devs+54} <ffffffff802ea496>{scsi_unjam_host+149}
<ffffffff802ea4a7>{scsi_error_handler+0} <ffffffff802ea506>{scsi_error_handler+95}
<ffffffff80144966>{kthread+129} <ffffffff8010b5a2>{child_rip+8}
<ffffffff8014498f>{keventd_create_kthread+0} <ffffffff801448e5>{kthread+0}
<ffffffff8010b59a>{child_rip+0}
Code: 83 3f 00 7e f9 e9 62 fe ff ff f3 90 83 3f 00 7e f9 e9 66 fe
console shuts up ...
--
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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: BUG: unable to handle kernel paging request at virtual address feededed (was: Re: Linux v2.6.17-rc5)
From: Tomasz Torcz @ 2006-06-04 17:01 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <Pine.LNX.4.64.0605301132180.5623@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 650 bytes --]
On Tue, May 30, 2006 at 11:44:03AM -0700, Linus Torvalds wrote:
> On Sun, 28 May 2006, Tomasz Torcz wrote:
> >
> > After 2 days and few hours uptime, during updatedb run I got:
> >
> > BUG: unable to handle kernel paging request at virtual address feededed
>
> I don't see anything suspicious anywhere, and this doesn't ring a bell.
> It is probably a good idea to open a bugzilla entry on it, so that it
> doesn't get lost.
Filed as http://bugzilla.kernel.org/show_bug.cgi?id=6641
--
Tomasz Torcz "Funeral in the morning, IDE hacking
zdzichu@irc.-nie.spam-.pl in the afternoon and evening." - Alan Cox
[-- Attachment #2: Type: application/pgp-signature, Size: 229 bytes --]
^ permalink raw reply
* Re: images -> DVD-slideshow ?
From: Hal MacArgle @ 2006-06-04 17:10 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <20060604075621.A26508@col7.metta.lk>
> * Hal MacArgle <haltec@kvinet.com> [2006-06-04 07:40]:
> > Another much more powerful scheme I've installed is cinelerra:
> > www.cinelerra.org
> > the heroinewarrior.com version that only installs into FedoraCore 4,
> > but includes all the deps in the 30mB rpm package.. I tried cinelerra
> > tarball but never got it working under Slack10.2..
Update: Compiled, not without some warnings, to Slackware10.2
with the "test26.s" kernel, rather than the default 2.4.31, that
failed, previously..
So far it works very well for what I've tried and there have
been no surprises that I experienced with FC4.. My favourite
Slackware, to the rescue.. <grin>
--
Hal - in Terra Alta, WV/US - Slackware GNU/Linux 10.1 (2.4.29)
.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: SMP HT + USB2.0 crash
From: Lee Revell @ 2006-06-04 17:10 UTC (permalink / raw)
To: Olaf Hering; +Cc: davor emard, Con Kolivas, linux-kernel
In-Reply-To: <20060604145420.GA26218@suse.de>
On Sun, 2006-06-04 at 16:54 +0200, Olaf Hering wrote:
> On Sun, Jun 04, davor emard wrote:
>
> > It happens on a production machine :(
>
> Either hire a professional sysadmin, or disable CONFIG_PREEMPT
Um, he said "production machine" not "web server". There are lots of
applications that require preemption.
Lee
^ permalink raw reply
* Re: [Qemu-devel] Configure doesn't honour CC variable
From: Nigel Horne @ 2006-06-04 17:11 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20060604162512.GB9335@mail.shareable.org>
[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]
Jamie Lokier wrote:
> Nigel Horne wrote:
>> When running "configure" I get
>>
>> 'ERROR: "gcc" looks like gcc 4.x'
>>
>> even though I've set the CC environment variable to point to my copy of
>> gcc version 3.2.2
>
> Qemu's configure is not like most other configure scripts.
Tut tut ;-)
> You have to use the --cc="$CC" command line option to Qemu's configure,
> to get it to use a different compiler.
>
> You might need to use the --host-cc="$CC" option as well.
Nope, that didn't work:
[njh@njh qemu]$ ./configure --cc=/home/njh/build_3.2.2_dir/gcc/xgcc
ERROR: "/home/njh/build_3.2.2_dir/gcc/xgcc" either does not exist or
does not work
[njh@njh qemu]$ ls -l /home/njh/build_3.2.2_dir/gcc/xgcc
-rwxrwxr-x 1 njh njh 85636 Aug 28 2005 /home/njh/build_3.2.2_dir/gcc/xgcc
[njh@njh qemu]$ ./configure --cc=/home/njh/build_3.2.2_dir/gcc/xgcc
--host-cc=/home/njh/build_3.2.2_dir/gcc/xgcc
ERROR: "/home/njh/build_3.2.2_dir/gcc/xgcc" either does not exist or
does not work
And before your say, yes, I am sure that my 3.2.2 build works.
> -- Jamie
-Nigel
[-- Attachment #2: njh.vcf --]
[-- Type: text/x-vcard, Size: 181 bytes --]
begin:vcard
fn:Nigel Horne
n:Horne;Nigel
org:NJH Music
email;internet:njh@bandsman.co.uk
tel;fax:+44 870 705 9334
note:Skype: nigelhorne
x-mozilla-html:FALSE
version:2.1
end:vcard
^ permalink raw reply
* Re: [RFC] Per-architecture randomization
From: Arjan van de Ven @ 2006-06-04 17:15 UTC (permalink / raw)
To: John Richard Moser; +Cc: linux-kernel
In-Reply-To: <44830703.3000905@comcast.net>
On Sun, 2006-06-04 at 12:14 -0400, John Richard Moser wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Arjan van de Ven wrote:
> > On Sun, 2006-06-04 at 00:14 -0400, John Richard Moser wrote:
> >> Pavel Machek recommended per-architecture randomization defaults when I
> >> poked a (very hackish) patch up here. As follow-up, I have taken out
> >> the command line parameter code and used the infrastructure I wrote to
> >> implement per-architecture randomization settings.
> >>
> >> Three #defines are needed per architecture, preferably in
> >> include/asm-ARCH/processor.h or equivalent. These defines are as follows:
> >>
> >> STACK_ALIGN -- Alignment of the stack, typically 16 (bytes).
> >> If not defined, stack randomization is carried out to page
> >> granularity
> >> ARCH_RANDOM_STACK_BITS -- Bits of entropy to apply to the stack.
> >> If not defined, stack randomization is disabled by defining this
> >> as 0.
> >> ARCH_RANDOM_MMAP_BITS -- Bits of entropy to apply to the mmap() base.
> >> If not defined, mmap() randomization is disabled by defining this
> >> as 0.
> >
> >
> > eh....
> >
> > I think you missed a few things..
> > like
> > 1) This is per architecture already for the most part!
> > arch_align_stack() is obvious per architecture already
>
> Yes you write a new one for each individual architecture, to tweak a few
> variables in it. Not that having the same function with the same blob
> of code with 1 or 2 numbers in it changed matters, since only 1 is
> generated to code...
well stack alignment IS a per architecture property, and on some
architectures it'll be more complex than a single one-liner (think about
a 32 bit userspace needing different alignment than 64 bit as a simple
example of this).
It's a 2 or 3 line function for the simple cases like x86 so... why
bother making it really complex.
> > Also you probably should explain what the advantage is over the existing
> > per architecture approach. Just stating "it's per architecture" (as you
> > suggest) doesn't cut it since it is per architecture already for the
> > most part.
>
> 1. I can get away with exactly 1 mmap() randomization function, instead
> of 1 function per architecture.
which needs to be there for other reasons anyway; VA space layout is a
per architecture thing no matter what (just look at ia64 or ppc on how
complex things can get), randomization within each region is, as a
result of that, also a per architecture thing; with different rules for
different part of the VA space sometimes (ia64/ppc64) or on the type of
userspace that happens to be running (on all architectures that also
have a compat arch)
> - Less code to maintain
we're talking less than a handful lines of code again, most of which is
NOT shareable.
> - The entropy levels are #defined per arch instead of hard-coded into
> functions (more readable in the future)
that's a separate thing; if you want to use a define rather than an open
coded value, fair enough, but make that a separate patch really;
especially since that is basically a "one line to a header + one line
code delta" which is then trivial to review for identity.
> 2. I can get away with exactly 1 arch_align_stack() function, instead
> of 1 per architecture.
I don't think that that is fundamentally possible, see above.
> 3. Entropy levels are rather easy to adjust and tweak per-architecture
> or per-compile or per-execve().
this I don't get; you change a per arch thing to.. a per arch thing.
> Part of the bulk stems from the fact that I didn't do randomization
> based on range, but based on bits of entropy.
I don't understand why you want to do that. It will make code a lot more
complex, and at the same time it limits you to powers-of-two in
practice.
> I became more comfortable
> with looking at entropy based on entropy instead of period*entropy
> mostly from reading through the PaX documents**.
Using bits-of-entropy in documentation is fine, you can do fractions
there as well for example. No objection from me on that, but it
shouldn't have to complicate or limit the code. For code, "range" is a
native principle much more than "bits of".
^ permalink raw reply
* Re: hardware limits
From: Dominik Brodowski @ 2006-06-04 17:15 UTC (permalink / raw)
To: Niels Borne; +Cc: cpufreq
In-Reply-To: <4481A0F4.5090702@laposte.net>
Hi,
On Sat, Jun 03, 2006 at 04:47:16PM +0200, Niels Borne wrote:
> >On Sun, May 28, 2006 at 09:37:11AM +0200, Niels Borne wrote:
> >>I am working on a vaio laptop pcg-fr415b, using fc5 (see result of cat
> >>/proc/cpuinfo above).
> >>Since it is quite noisy I allowed cpuspeed at startup and this improved
> >>the situation a little bit.
> >>Still cpufreq-info (see details above -in french, but you can guess) gives
> >>hardware limits : 2.10 GHz - 2.80 GHz
> >>Is there any hope to go below 2.10 GHz and if yes, how ?
> >
> >Unfortunately no -- there's a bug in the hardware which causes problems if
> >the frequency is lower than 2 GHz.
>
> Which hardware exactly ? It this related to the N60 errata ?
Yes, that's the N60 errata.
> Also, p4-clockmod doesn't save you all
> >that much (if at all)
>
> well it seems to improve somewhat
>
> as it doesn't do CPU frequency and voltage scaling,
>
> what do you mean ? my frequency is now most often 2.10 GHz, and was 2.80
> GHz, so it does CPU frequency, doesn't it ?
It doesn't scale the frequency, it throttles it -- and that means that the
voltage cannot be dropped:
"In contrast to CPU frequency scaling, where the operating frequency is
constantly modulated, throttling means the CPU is forced to a halt for short
periods of time. If throttled, the CPU [enters] into a physical and
electrical state comparable to the idling states mentioned above, so it can
be described as an enforced idling of the CPU.
As certain CPU power state typically utilize similar hardware
implementations, and as throttling does not have a positive effect on the
energy consumption during CPU power states, throttling the CPU by a given
rate is only useful if the CPU is less idle than the throttling rate."
Dominik
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
From: Oliver Neukum @ 2006-06-04 17:17 UTC (permalink / raw)
To: John Que
Cc: Daniel Drake, linux-usb-devel, John W. Linville, netdev,
Ulrich Kunitz
In-Reply-To: <ada605fb0606040929p7a6ea69aw9488a75d611b23e5@mail.gmail.com>
Am Sonntag, 4. Juni 2006 18:29 schrieb John Que:
> I had noticed that the zd1211 driver does call request_irq() in zd1205_open(),
> file zd1205.c; grepping for request_irq() in the rewrite driver yields
> no results.
> (I looked at the rewrite version from a week ago but in this point it
> is probably the
> same).
> Why is this so ? I assume that the softmac layer does not call request_irq() on
> behalf of the driver because this is not supposed to be like it, as I understand
> its functionality. Can anybody briefly calrify this point ?
A USB driver never will request an irq. Interrupt handling is done in
the core usb layer. Individual drivers have no business there.
Regards
Oliver
^ permalink raw reply
* [lm-sensors] sysfs interface for fan present capability
From: Henrique de Moraes Holschuh @ 2006-06-04 17:18 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <4482843D.5020506@hhs.nl>
On Sun, 04 Jun 2006, Jean Delvare wrote:
> Sure, why not. fan[1-*]_present sounds like a good idea. I wonder how
> this works physically. It would be great if other chips could implement
> this feature, that would make autoconfig easier for fans. If you
We can certainly implement it as in-driver logic if the hardware doesn't
cooperate, but a stuck fan on startup will be shown as not-present unless
you DO have hardware detection.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply
* Re: [PATCH] Hardware P-state driver for AMD Opterons, etc.
From: Dominik Brodowski @ 2006-06-04 17:18 UTC (permalink / raw)
To: Langsdorf, Mark; +Cc: cpufreq
In-Reply-To: <84EA05E2CA77634C82730353CBE3A843053503D0@SAUSEXMB1.amd.com>
Hi,
On Fri, Jun 02, 2006 at 05:45:24PM -0500, Langsdorf, Mark wrote:
> +static int cpu_family = CPU_OPTERON;
...
> + if (cpu_family)
> + return 0;
> +
...
> + if (cpu_family) {
> + rdmsr(MSR_PSTATE_STATUS, lo, hi);
...
I'd prefer it if all these if cases would be made explicit:
if (cpu_family == CPU_OPTERON)
as that makes the code much more readable.
Thanks,
Dominik
^ permalink raw reply
* [lm-sensors] sysfs interface for fan present capability
From: Hans de Goede @ 2006-06-04 17:20 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <4482843D.5020506@hhs.nl>
Jean Delvare wrote:
> Hi Hans,
>
>> It looks like I've discover yet another feature of the uguru, a bit in
>> the fan bank which seemed to be sometimes 1 sometimes 0 actually seems
>> to indicate whether a fan is present or not. I'm not 100% sure, but I'm
>> starting to see a pattern and sofar it holds in 100% of the cases I
>> have. I'll buy myself an extra 3 wire fan and put it on the aux fan
>> connectors then I'll know for sure soon enough.
>>
>> Which brings me to the question, do we want to export this to userspace
>> (I guess we do) and if we do how. May I suggest a readonly boolean
>> fan[1-x]_present?
>
> Sure, why not. fan[1-*]_present sounds like a good idea. I wonder how
> this works physically.
I think they are just seeing if it gives any "ticks" at all, so it won't
detect a 2 wire fan even if connected to one if its headers.
And as said I'm not even sure it does that, its basicly a mistery bit in
the uguru which I think does this :) When I have some more spare time
and renewed energy for the uGuru I'll try to connect a 3 wire fan to my
other fan headers and see what happens.
Regards,
Hans
^ permalink raw reply
* Re: images -> DVD-slideshow ?
From: Hal MacArgle @ 2006-06-04 17:23 UTC (permalink / raw)
To: Bhikkhu Mettavihari; +Cc: linux-newbie
In-Reply-To: <20060604075621.A26508@col7.metta.lk>
On 06-04, Bhikkhu Mettavihari wrote:
> Lovely, lively,
> It was indeed hard to get started.
> There is a list on cinelerra where you could get much info.
>
> There is a link to a slackware site on www.cinelerra.org
> if you do "wget -r -np to that site" you should get most of the
> dependencies. If you have any problems please email me privately on
> mettavihari@gmail.com or ask on the cinelerra mailing list.
Greetings and -- Appreciate!! Will try the above. Thanks..
Let me get some more time with the successfully compiled tarball on
Slackware10.2, test26.s kernel.. I'm sure I'll have some queries..
Didn't know there was a list. Missed that.. <grin> I was able to
fetch the 300, or so, pages of HTML docs.. Plenty of studying..
> I will have a look at lvempeg.sf.net
> It sounds interesting and challenging
Be __very__ interested in hearing if you are able to load a
file into it.. I sure missed something.. Trouble is; cinelerra spoils
one though..
> There is also a interface for making dvd's but i have not mastered yet.
> May be in about 1-2 weeks I should be able to help.
Burning DVD's that play on a stand alone consumer player not
a problem as Chuck and Ray figured out a few weeks ago.. At least
from captured .avi files, non edited..
Best,
--
Hal - in Terra Alta, WV/US - Slackware GNU/Linux 10.1 (2.4.29)
.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: scsi layer differences between 2.4 and 2.6
From: Tim Cullen @ 2006-06-04 17:31 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: linux-scsi
In-Reply-To: <1149293976.3109.2.camel@laptopd505.fenrus.org>
What is happening is that read and write performance
are lower on a 2.6 (SLES9 SP2) based kernel than on a
2.4 based kernel.
The test hardware is a Cray XT3 connected to a DDN
S2A8500 RAID array. The test is sequential reads and
writes from programs like sgp_dd and ior.
To be more specific, 2.4 peforms much better with IO
transfer sizes of 64k than the 2.6 kernel does. And in
some cases performs better with 1MB transfer sizes.
tim
--- Arjan van de Ven <arjan@infradead.org> wrote:
> On Fri, 2006-06-02 at 14:23 -0700, Tim Cullen wrote:
> > Several of our customers as well as those of our
> > partners have been inquiring about a performance
> > regression that looks like its being caused by the
> > scsi layer in the 2.6 kernel. Compared to the
> > performance that can been seen using the same
> hardware
> > with a 2.4 kernel.
> >
> > Can somebody give me a summary of the changes that
> > were made to the scsi layer between 2.4 and 2.6?
>
> "it got rewritten".
>
> Can you provide more information on what is
> happening? Like which
> hardware, which drivers, what kind of workloads etc
> ?
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* [PATCH] cpufreq-nforce2 divider
From: Sebastian Witt @ 2006-06-04 17:42 UTC (permalink / raw)
To: cpufreq
Patch against 2.6.16. Sets minimum PLL divider to 2. No negative impact when
tested with two nForce2 based boards. (Updates also the (C) year)
Signed-off-by: Sebastian Witt <se.witt <at> gmx net>
---
--- linux-2.6.16-gentoo-r7.orig/arch/i386/kernel/cpu/cpufreq/cpufreq-nforce2.c
2006-06-04 19:32:29.000000000 +0200
+++ linux-2.6.16-gentoo-r7/arch/i386/kernel/cpu/cpufreq/cpufreq-nforce2.c
2006-06-04 19:32:42.000000000 +0200 @@ -1,5 +1,5 @@
/*
- * (C) 2004 Sebastian Witt <se.witt@gmx.net>
+ * (C) 2004-2006 Sebastian Witt <se.witt@gmx.net>
*
* Licensed under the terms of the GNU GPL License version 2.
* Based upon reverse engineered information
@@ -90,7 +90,7 @@
/* Try to calculate multiplier and divider up to 4 times */
while (((mul == 0) || (div == 0)) && (tried <= 3)) {
- for (xdiv = 1; xdiv <= 0x80; xdiv++)
+ for (xdiv = 2; xdiv <= 0x80; xdiv++)
for (xmul = 1; xmul <= 0xfe; xmul++)
if (nforce2_calc_fsb(NFORCE2_PLL(xmul, xdiv)) ==
fsb + tried) {
^ permalink raw reply
* Re: scsi layer differences between 2.4 and 2.6
From: Arjan van de Ven @ 2006-06-04 17:42 UTC (permalink / raw)
To: Tim Cullen; +Cc: linux-scsi
In-Reply-To: <20060604173132.30735.qmail@web30312.mail.mud.yahoo.com>
On Sun, 2006-06-04 at 10:31 -0700, Tim Cullen wrote:
> What is happening is that read and write performance
> are lower on a 2.6 (SLES9 SP2) based kernel than on a
> 2.4 based kernel.
>
> The test hardware is a Cray XT3 connected to a DDN
> S2A8500 RAID array. The test is sequential reads and
> writes from programs like sgp_dd and ior.
what is the HBA in use? (eg which driver?)
^ permalink raw reply
* [lm-sensors] sysfs interface for fan present capability
From: Henrique de Moraes Holschuh @ 2006-06-04 17:42 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <4482843D.5020506@hhs.nl>
On Sun, 04 Jun 2006, Hans de Goede wrote:
> I think they are just seeing if it gives any "ticks" at all, so it won't
> detect a 2 wire fan even if connected to one if its headers.
Two-wire fans can be detected just as well as three-wire ones, if you
measure current draw :) In fact, some chips (like the lm75) can actually
COUNT ticks on two-wire fans by measuring spikes in the current draw...
If you detect fan presence using ticks, you will never detect a stuck fan on
startup, which is *dangerous* as it could cause the software inhibit an
alarm on that fan.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply
* Re: [PATCH] klibc
From: H. Peter Anvin @ 2006-06-04 17:42 UTC (permalink / raw)
To: David Miller; +Cc: maks, linux-kernel, klibc
In-Reply-To: <20060603.233034.59468148.davem@davemloft.net>
David Miller wrote:
>
>> __arch64__ is ugly; it doesn't say it's a sparc thing. I have added
>> -D__sparc_v9__ to the sparc64 MCONFIG file, so I think that's fine.
>>
>> Perhaps the right thing to do is to make this an archconfig.h configurable.
>
> Please don't do this, I'll explain why.
>
> Using __sparc_v9__ is incorrect, here is the lowdown on these defines:
>
> 1) __sparc_v9__ means "-mcpu={ultrasparc*,niagara}" or "-mcpu=v9".
> Although this is implied by "-m64" it can be used for 32-bit
> code too.
>
> __sparc_v9__ means "using v9 instructions" which does not
> necessarily mean 64-bit
>
> 2) "__sparc__ && __arch64__" means 64-bit sparc
>
> People often get this wrong, and it certainly is confusing.
>
Okay, how about __sparc64__ then (via -D in the MCONFIG file.)
I did change this particular instance to be a archconfig variable, so it
doesn't exist (I try very much to avoid architecture-specific #ifdefs in
bulk code.)
-hpa
^ 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.