[BUG] 3w-9xxx BUG in 2.6.32
Hi, I have a Quanta S45 motherboard that I'm trying to install Debian 6.0 on with a 3Ware 9650-4LPML RAID card. When the Debian installer inserts the 3w-9xxx module, I get the following kernel BUG. I've tried a different 9650 card and booting with acpi=off to no avail so far. I'm assuming it's a weird MB issue. Does anyone know of a fix/workaround? Please CC me for I am not subscribed. Thanks. -- James Jan 21 20:31:26 kernel: [ 31.609437] 3ware 9000 Storage Controller device driver for Linux v2.26.02.013. Jan 21 20:31:26 kernel: [ 31.609479] 3w-9xxx :03:00.0: PCI->APIC IRQ transform: INT A -> IRQ 16 Jan 21 20:31:26 kernel: [ 31.609484] 3w-9xxx :03:00.0: setting latency timer to 64 ... Jan 21 20:31:57 kernel: [ 61.868012] 3w-9xxx: scsi7: ERROR: (0x06:0x0003): No valid response while draining AEN queue. Jan 21 20:31:57 kernel: [ 61.868016] 3w-9xxx: scsi7: ERROR: (0x06:0x0022): AEN drain failed during reset sequence. Jan 21 20:32:07 kernel: [ 72.208012] 3w-9xxx: scsi7: AEN: INFO (0x04:0x0053): Battery capacity test is overdue:. Jan 21 20:32:07 kernel: [ 72.320014] 3w-9xxx: scsi7: AEN: INFO (0x04:0x0053): Battery capacity test is overdue:. Jan 21 20:32:07 kernel: [ 72.432014] 3w-9xxx: scsi7: AEN: INFO (0x04:0x0001): Controller reset occurred:resets=1. Jan 21 20:32:07 kernel: [ 72.544007] scsi7 : 3ware 9000 Storage Controller Jan 21 20:32:07 kernel: [ 72.544082] 3w-9xxx: scsi7: Found a 3ware 9000 Storage Controller at 0xdf5ff000, IRQ: 16. Jan 21 20:32:38 kernel: [ 102.568007] 3w-9xxx: scsi7: ERROR: (0x06:0x0013): No valid response during get param. Jan 21 20:32:38 kernel: [ 102.568018] BUG: unable to handle kernel NULL pointer dereference at (null) Jan 21 20:32:38 kernel: [ 102.572002] IP: [] twa_probe+0x541/0x714 [3w_9xxx] Jan 21 20:32:38 kernel: [ 102.572002] PGD 43a17f067 PUD 43c6c0067 PMD 0 Jan 21 20:32:38 kernel: [ 102.572002] Oops: [#1] SMP Jan 21 20:32:38 kernel: [ 102.572002] last sysfs file: /sys/devices/pci:00/:00:19.0/net/eth0/uevent Jan 21 20:32:38 kernel: [ 102.572002] CPU 0 Jan 21 20:32:38 kernel: [ 102.744014] Modules linked in: e1000e 3w_9xxx(+) nls_utf8 isofs sg sr_mod cdrom hid_microsoft usbhid hid thermal_sys usb_storage uhci_hcd ehci_hcd ahci li Jan 21 20:32:38 kernel: [ 102.744014] Pid: 3265, comm: modprobe Not tainted 2.6.32-5-amd64 #1 S45 Jan 21 20:32:38 kernel: [ 102.744014] RIP: 0010:[] [] twa_probe+0x541/0x714 [3w_9xxx] Jan 21 20:32:38 kernel: [ 102.744014] RSP: 0018:880437cdfd98 EFLAGS: 00010292 Jan 21 20:32:38 udevd-work[3259]: '/sbin/modprobe -b pci:v13C1d1004sv13C1sd1004bc01sc04i00' unexpected exit with status 0x0009 Jan 21 20:32:38 kernel: [ 102.744014] RAX: RBX: 88043e601090 RCX: 0004 Jan 21 20:32:38 kernel: [ 102.744014] RDX: 0402 RSI: 0001 RDI: 8804370445a0 Jan 21 20:32:38 kernel: [ 102.744014] RBP: 8804370445a0 R08: 0010 R09: 813b0932 Jan 21 20:32:38 kernel: [ 102.744014] R10: R11: 000186a0 R12: df5ff000 Jan 21 20:32:38 kernel: [ 102.744014] R13: 88043e601000 R14: 880437044000 R15: Jan 21 20:32:38 kernel: [ 102.744014] FS: 7f64f8eb9700() GS:88000fa0() knlGS: Jan 21 20:32:38 kernel: [ 102.744014] CS: 0010 DS: ES: CR0: 8005003b Jan 21 20:32:38 kernel: [ 102.744014] CR2: CR3: 00043989d000 CR4: 06f0 Jan 21 20:32:38 kernel: [ 102.744014] DR0: DR1: DR2: Jan 21 20:32:38 kernel: [ 102.744014] DR3: DR6: 0ff0 DR7: 0400 Jan 21 20:32:38 kernel: [ 102.744014] Process modprobe (pid: 3265, threadinfo 880437cde000, task 88043c6adbd0) Jan 21 20:32:38 kernel: [ 102.744014] Stack: Jan 21 20:32:38 kernel: [ 102.744014] 88043e601000 88043e601090 Jan 21 20:32:38 kernel: [ 102.744014] <0> a00ff970 00405047 811a2d46 Jan 21 20:32:38 kernel: [ 102.744014] <0> 88043e601000 811a3996 a00ff970 88043e601000 Jan 21 20:32:38 kernel: [ 102.744014] Call Trace: Jan 21 20:32:38 kernel: [ 102.744014] [] ? local_pci_probe+0x12/0x16 Jan 21 20:32:38 kernel: [ 102.744014] [] ? pci_device_probe+0xc0/0xe9 Jan 21 20:32:38 kernel: [ 102.744014] [] ? driver_probe_device+0xa3/0x14b Jan 21 20:32:38 kernel: [ 102.744014] [] ? __driver_attach+0x4f/0x6f Jan 21 20:32:38 kernel: [ 102.744014] [] ? __driver_attach+0x0/0x6f Jan 21 20:32:38 kernel: [ 102.744014] [] ? bus_for_each_dev+0x43/0x74 Jan 21 20:32:38 kernel: [ 102.744014] [] ? bus_add_driver+0xaf/0x1f8 Jan 21 20:32:38 kernel: [ 102.744014] [] ? driver_register+0xa7/0x111 Jan 21 20:32:38 kernel: [ 102.744014] [] ? twa_init+0x0/0x35 [3w_9xxx] Jan 21 20:32:38 kernel: [ 102.744014] [] ? __
Re: [RFH] Partion table recovery
On 7/19/07, Al Boldi <[EMAIL PROTECTED]> wrote: As always, a good friend of mine managed to scratch my partion table by cat'ing /dev/full into /dev/sda. I was able to push him out of the way, but at least the first 100MB are gone. I can probably live without the first partion, but there are many partitions after that, which I hope should easily be recoverable. I tried parted, but it's not working out for me. Does anybody know of a simple partition recovery tool, that would just scan the disk for lost partions? Tried gpart? http://www.stud.uni-hannover.de/user/76201/gpart/ Thanks! -- Al -- James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
More FTDI 232BM chip issues...
Earlier I posted about having long delay issues when reading back bytes from a FTDI 232BM USB->Serial chip. Now, I've noticed that after a long period of time of semi-continual use (maybe 8+ hours) I see the following messages in my kernel.log: Mar 24 23:46:42 displaytest kernel: hub 2-0:1.0: port 2 disabled by hub (EMI?), re-enabling... Mar 24 23:46:42 displaytest kernel: usb 2-2: USB disconnect, address 4 Mar 24 23:46:42 displaytest kernel: ftdi_sio 2-2:1.0: device disconnected Mar 24 23:46:42 displaytest kernel: usb 2-2: new full speed USB device using address 5 Mar 24 23:46:42 displaytest kernel: ftdi_sio 2-2:1.0: FTDI FT232BM Compatible converter detected Mar 24 23:46:42 displaytest kernel: usb 2-2: FTDI FT232BM Compatible converter now attached to ttyUSB1 Of course I have a test program running overnight and when the device comes back up it switches device names (because my test program has the port still open), which causes it to die at that point. Is there any particular reason the hub would disable that port? Or am I in flakey hardware land here? Thanks. -- James Lamanna - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[linux-usb-devel] Long delay on serial-usb echo readback
I have the following setup: FTDI USB->Serial chip hooked up to a CAN signaling transceiver. Due to the nature of CAN, I automatically get local echo back through the FTDI chip. I'm not using the CAN protocol, but just its signaling properties. The problem I am having is everytime I write something I must read back what I've written in order to read back correct data from the device it is hooked up to, because of CAN having hardware echo. I am finding that if the string that I send is long enough (usually greater than 22 bytes in most cases), the FTDI chip splits the response into at least two IN data packets. Unfortunately there is a large delay between these two packets (for a write of 64 bytes its usually around 19ms @ 115200 baud). I'm wondering if this delay can be shortened or if it is the result of USB hardware on either end (either the FTDI chip or the USB hardware/stack on the computer side). This is with vanilla linux-2.6.11. A sample transaction with lots of debugging looks like the following: FTDI FT232BM Compatible ttyUSB0: ftdi_write - length = 64, data = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 drivers/usb/serial/ftdi_sio.c: sent write urb, count 64, at 0us drivers/usb/serial/ftdi_sio.c: ftdi_write write returning: 64 drivers/usb/serial/ftdi_sio.c: ftdi_chars_in_buffer - port 0 drivers/usb/serial/ftdi_sio.c: ftdi_write_room - port 0 drivers/usb/serial/ftdi_sio.c: ftdi_write_bulk_callback - port 0 drivers/usb/serial/ftdi_sio.c: ftdi_chars_in_buffer - port 0 drivers/usb/serial/ftdi_sio.c: ftdi_write_room - port 0 drivers/usb/serial/ftdi_sio.c: 89: ftdi_read_bulk_callback at 2895us data_count 25 drivers/usb/serial/ftdi_sio.c: ftdi_read_bulk_callback - port 0 drivers/usb/serial/ftdi_sio.c: ftdi_process_read - port 0 FTDI FT232BM Compatible ttyUSB0: ftdi_process_read - length = 25, data = 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 drivers/usb/serial/ftdi_sio.c: 90: ftdi_process send urb at 2925us drivers/usb/serial/ftdi_sio.c: ftdi_chars_in_buffer - port 0 drivers/usb/serial/ftdi_sio.c: ftdi_write_room - port 0 drivers/usb/serial/ftdi_sio.c: ftdi_chars_in_buffer - port 0 drivers/usb/serial/ftdi_sio.c: ftdi_write_room - port 0 drivers/usb/serial/ftdi_sio.c: 90: ftdi_read_bulk_callback at 18893us data_count 43 drivers/usb/serial/ftdi_sio.c: ftdi_read_bulk_callback - port 0 drivers/usb/serial/ftdi_sio.c: ftdi_process_read - port 0 FTDI FT232BM Compatible ttyUSB0: ftdi_process_read - length = 43, data = 01 60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 drivers/usb/serial/ftdi_sio.c: 91: ftdi_process send urb at 18938us drivers/usb/serial/ftdi_sio.c: ftdi_chars_in_buffer - port 0 drivers/usb/serial/ftdi_sio.c: ftdi_write_room - port 0 drivers/usb/serial/ftdi_sio.c: ftdi_close drivers/usb/serial/ftdi_sio.c: 91: ftdi_read_bulk_callback at 22891us data_count 0 drivers/usb/serial/ftdi_sio.c: ftdi_read_bulk_callback - port 0 Thanks in advance, -- James Lamanna - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel OOPS with i915 DRM Driver - 2.6.10
Noticed this oops today when setting up a box with a i865G chipset:
I'm using Xorg 6.8.0.
I also experience virtual terminal corruption when I switch to any of
them after X starts up.
Thanks.
-- James Lamanna
drm:i830_dma_initialize] *ERROR* can not find dma buffer map!
[drm:i830_irq_emit] *ERROR* i830_irq_emit called without lock held
Unable to handle kernel paging request at virtual address f000e829
printing eip:
c02793c1
*pde =
Oops: [#1]
PREEMPT SMP
Modules linked in:
CPU:1
EIP:0060:[]Not tainted VLI
EFLAGS: 00013296 (2.6.10-gentoo-r6)
EIP is at i830_kernel_lost_context+0x11/0x70
eax: f000e819 ebx: ecx: 000c edx: 3282
esi: c05a99a0 edi: ebp: esp: db26fecc
ds: 007b es: 007b ss: 0068
Process X (pid: 8049, threadinfo=db26f000 task=de4d3020)
Stack: c027b4a7 c05a99a0 3282 c01270d7 c027bed0 c05a99a0 c027bedf
c05a99a0 c0274fd4 c05a99a0 c05aa0d8 c05aa0e0
0001 000a de4d3020 c01187e0
Call Trace:
[] i830_dma_quiescent+0x17/0xb0
[] block_all_signals+0x37/0x80
[] i830_driver_dma_quiescent+0x0/0x20
[] i830_driver_dma_quiescent+0xf/0x20
[] i830_lock+0x264/0x310
[] default_wake_function+0x0/0x20
[] default_wake_function+0x0/0x20
[] dput+0x33/0x1d0
[] i830_ioctl+0xe5/0x160
[] fget+0x49/0x60
[] sys_ioctl+0xca/0x230
[] syscall_call+0x7/0xb
Code: b9 8b 53 0c 01 d0 89 43 1c e9 60 ff ff ff 8d b6 00 00 00 00 8d
bf 00 00 00 00 53 8b 44 24 08 8b 98 34 07 00 00 8b 43 04 8d 4b 0c <8b>
40 10 8b 90 34 20 00 00 81 e2 fc ff 1f 00 89 51 14 8b 43 04
relevant parts of .config:
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.10-gentoo-r6
# Mon Jan 24 17:30:52 2005
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_LOCK_KERNEL=y
#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_LOG_BUF_SHIFT=15
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
# CONFIG_IKCONFIG is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y
#
# Processor type and features
#
CONFIG_X86_PC=y
CONFIG_MPENTIUM4=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_HPET_TIMER is not set
CONFIG_SMP=y
CONFIG_NR_CPUS=8
CONFIG_SCHED_SMT=y
CONFIG_PREEMPT=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
CONFIG_X86_MCE_P4THERMAL=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_IRQBALANCE=y
CONFIG_HAVE_DEC_LOCK=y
# CONFIG_REGPARM is not set
CONFIG_AGP=y
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
CONFIG_AGP_INTEL=y
CONFIG_AGP_INTEL_MCH=y
# CONFIG_AGP_NVIDIA is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_EFFICEON is not set
CONFIG_DRM=y
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_I810 is not set
# CONFIG_DRM_I830 is not set
CONFIG_DRM_I915=y
CONFIG_FB=y
CONFIG_FB_MODE_HELPERS=y
# CONFIG_FB_TILEBLITTING is not set
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
CONFIG_FB_VESA=y
# CONFIG_FB_VESA_STD is not set
CONFIG_FB_VESA_TNG=y
CONFIG_FB_VESA_DEFAULT_MODE="[EMAIL PROTECTED]"
# CONFIG_VIDEO_SELECT is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I810 is not set
# CONFIG_FB_INTEL is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON_OLD is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is n
Re: [patch 1/13] Qsort
> On Sunday, January 23, 2005, Rafael J. Wysocki wrote:
> > On Sunday, 23 of January 2005 06:05, Jesper Juhl wrote:
> > > On Sun, 23 Jan 2005, Andi Kleen wrote:
> > Even with large data sets that are mostly unsorted shell sorts performance
> > is close to qsort, and there's an optimization that gives it O(n^(3/2))
> > runtime (IIRC),
>
> Yes, there is.
After doing a small amount of research into this, according to the abstract at
http://www.cs.princeton.edu/~rs/shell/paperF.pdf you can get O(n^(4/3))
with different increment sequences. (1, 8, 23, 77, 281 ...)
So I guess the sort function could look something like this for XFS use
(for reference only!):
void shellsort(void *array, size_t total_elems, size_t size,
int (*cmp)(const void *, const void *))
{
size_t i, j;
int k, h;
register char *a = array;
const int incs[3] = {23, 8, 1};
for (k = 0; k < 3; k++) {
for (h = incs[k], i = h; i < total_elems; i++) {
j = i;
while (j >= h && cmp(a + (j-h) * size, a + j * size) > 0) {
swap(a + j * size, a + (j-h) * size);
j -= h;
}
}
}
}
-- James Lamanna
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
waitqueues 2.2->2.4
Again, I"m working on converting a module from 2.2 to being compatible with 2.4. In the 2.2 version it uses wait_queue structs with function calls such as wake_up(), interruptible_sleep_on()... In 2.4 these have changed to accept wait_queue_head_t's. What is the correct way to convert to the new way of doing things? And on another note, what is the best way to debug a module that crashes in an interrupt routine? (the oops info doesn't get logged anywhere since it crashes in the ISR). * Please CC to me since I'm not subscribed... Thanks, --James Lamanna - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
More module conversion...
In my quest to convert a module from 2.2 to 2.4, I came across a nice oops (it actually was from their code that I thought I didn't have to touch...). The oops comes when trying to access address 0xd2000, which the code for this robot controller has hardcoded as its "BASE_ADDR" Were the base addresses for io cards moved between 2.2 and 2.4? * Please cc me since I'm not currently subscribed. Thanks, --James Lamanna ksymoops 2.4.0 on i686 2.4.5. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.5/ (default) -m /usr/src/linux-2.4.5/System.map (specified) Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not found in System.map. Ignoring ksyms_base entry Jun 25 15:10:08 martel kernel: Unable to handle kernel paging request at virtual address 000d2000 Jun 25 15:10:08 martel kernel: c8853cc0 Jun 25 15:10:08 martel kernel: *pde = Jun 25 15:10:08 martel kernel: Oops: Jun 25 15:10:08 martel kernel: CPU:0 Jun 25 15:10:08 martel kernel: EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 Jun 25 15:10:08 martel kernel: EFLAGS: 00010286 Jun 25 15:10:08 martel kernel: eax: 000d2000 ebx: 00fd ecx: c748e000 edx: c0244b64 Jun 25 15:10:08 martel kernel: esi: edi: ebp: c8854780 esp: c6a11ef0 Jun 25 15:10:08 martel kernel: ds: 0018 es: 0018 ss: 0018 Jun 25 15:10:08 martel kernel: Process insmod (pid: 1071, stackpage=c6a11000) Jun 25 15:10:08 martel kernel: Stack: 0001 c028853c 0019 00fd 0806e918 c8853f66 Jun 25 15:10:08 martel kernel:c8854780 00fd c8854640 c8853000 c8853000 c0111a05 Jun 25 15:10:08 martel kernel: c63a8000 16a0 c63a9000 0060 ffea 0005 c6b25e00 Jun 25 15:10:08 martel kernel: Call Trace: [] [] [] [] [] [] [] Jun 25 15:10:08 martel kernel:[] [] Jun 25 15:10:08 martel kernel: Code: 0f b6 34 07 89 f2 80 fa ff 74 08 84 d2 0f 85 09 01 00 00 47 >>EIP; c8853cc0 <[i200m]i200m_probe+20/168> <= Trace; c8853f66 <[i200m]init_module+e2/138> Trace; c8854780 <[i200m]__module_kernel_version+0/0> Trace; c8854640 <[i200m]i200m_fops+0/5f> Trace; c8853000 <[wvlan_cs]__module_parm_station_name+12e98/12ef8> Trace; c8853000 <[wvlan_cs]__module_parm_station_name+12e98/12ef8> Trace; c0111a05 Trace; c883a000 <[ds].data.end+15c1/1621> Trace; c8853060 <[i200m]i200m_boot_command+0/d4> Trace; c0106c4b Code; c8853cc0 <[i200m]i200m_probe+20/168> <_EIP>: Code; c8853cc0 <[i200m]i200m_probe+20/168> <= 0: 0f b6 34 07 movzbl (%edi,%eax,1),%esi <= Code; c8853cc4 <[i200m]i200m_probe+24/168> 4: 89 f2 mov%esi,%edx Code; c8853cc6 <[i200m]i200m_probe+26/168> 6: 80 fa ff cmp$0xff,%dl Code; c8853cc9 <[i200m]i200m_probe+29/168> 9: 74 08 je 13 <_EIP+0x13> c8853cd3 <[i200m]i200m_probe+33/168> Code; c8853ccb <[i200m]i200m_probe+2b/168> b: 84 d2 test %dl,%dl Code; c8853ccd <[i200m]i200m_probe+2d/168> d: 0f 85 09 01 00 00 jne11c <_EIP+0x11c> c8853ddc <[i200m]i200m_probe+13c/168> Code; c8853cd3 <[i200m]i200m_probe+33/168> 13: 47inc%edi 1 warning issued. Results may not be reliable. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Making a module 2.4 compatible
I have a kernel module for a robot that was developed for the 2.0 and 2.2 kernels and does not work under 2.4. Unfortunately, the company that made it is not in business anymore. It would be nice to have it working under 2.4, so is there someplace that outlines some of the major things that would have changed so I can update the module accordingly? Thanks, --James Lamanna - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with PDC202xx driver
Here is an excerpt from /proc/pci: Bus 0, device 11, function 0: RAID bus controller: Promise Technology, Inc. 20267 (rev 2). IRQ 10. Master Capable. Latency=32. I/O at 0x9400 [0x9407]. I/O at 0x9000 [0x9003]. I/O at 0x8800 [0x8807]. I/O at 0x8400 [0x8403]. I/O at 0x8000 [0x803f]. Non-prefetchable 32 bit memory at 0xd500 [0xd501]. Bus 0, device 17, function 0: Unknown mass storage controller: Promise Technology, Inc. 20265 (rev 2). IRQ 10. Master Capable. Latency=32. I/O at 0x7800 [0x7807]. I/O at 0x7400 [0x7403]. I/O at 0x7000 [0x7007]. I/O at 0x6800 [0x6803]. I/O at 0x6400 [0x643f]. Non-prefetchable 32 bit memory at 0xd480 [0xd481]. > Now if you have a device that reports it storage class as RAID then it may > misbehave. Otherwise, if it is reporting "Unknown Mass Storage" then you > have an Ultra/ATA controller. It would seem that it reports itself as both. > > There are two different BIOS cores for each design. > Linux cleanly supports the BIOS cores know as "Ultra" and not the ones > know as "Fasttrak". Is there a plan to support the Fasttrak BIOS core at some point (I hope..) So I guess I'm stuck with loading their proprietary module whenever I want to use the drive But thanks for the clarification. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with PDC202xx driver
So you are saying that the Promise Fasttrak 100 chipset is designed wrong? Because that's exactly what I have. and isn't this driver supposed to support it? Or are you saying the IDE controller on the MB is wrong? Andre Hedrick wrote: > > <4>ide: Assuming 33MHz system bus speed for PIO modes > <4>AMD7409: IDE controller on PCI bus 00 dev 39 > <4>AMD7409: chipset revision 7 > <4>AMD7409: not 100% native mode: will probe irqs later > <4>ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA > <4>ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA > <4>PDC20267: IDE controller on PCI bus 00 dev 48 > <4>PDC20267: chipset revision 2 > <4>PDC20267: not 100% native mode: will probe irqs later > <4>PDC20267: ROM enabled at 0xe800 > <4>PDC20267: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode. > <4>ide2: BM-DMA at 0xd400-0xd407, BIOS settings: hde:DMA, hdf:pio > <4>ide3: BM-DMA at 0xd408-0xd40f, BIOS settings: hdg:DMA, hdh:pio > <4>hda: QUANTUM FIREBALL CX13.0A, ATA DISK drive > <4>hdb: QUANTUM FIREBALL CR4.3A, ATA DISK drive > <4>hdc: ATAPI CD ROM DRIVE 50X MAX, ATAPI CDROM drive > <4>hde: Maxtor 91536H2, ATA DISK drive > <4>ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > <4>ide1 at 0x170-0x177,0x376 on irq 15 > <4>ide2 at 0xc400-0xc407,0xc802 on irq 11 > > Nope you have a chipset that is designed wrong. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Problems with PDC202xx driver
Whenever I tried using the PDC202xx driver in 2.4-test11 I kept receiving the line in dmsg: PDC20267: neither IDE port enabled (BIOS) I traced this to ide-pci.c, line 606: if (e->reg && (pci_read_config_byte(dev, e->reg, &tmp) || (tmp & e->mask) != e->val)) continue; /* port not enabled */ This if was returning true, and skipping the rest of the loop (which sets up the ioports...) So it looks like to me that it's not enabling the IOPorts for this chipset. This seems like a really bad thing, considering that I can gain no access to the drives currently using this driver. Any suggestions? Thanks, --James Lamanna - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
pdc202xx driver problems
Using kernel 2.4.0-test10... It seems to detect the controller card and the drives, but they are not assigned to any devices after boot up. I know that the RAID won't work, but I guess I thought it would setup the 2 drives I have connected. Any suggestions? Thanks, --James Lamanna Here is some info: dmesg: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PDC20265: IDE controller on PCI bus 00 dev 88 PDC20265: chipset revision 2 PDC20265: not 100% native mode: will probe irqs later PDC20265: (U)DMA Burst Bit DISABLED Primary PCI Mode Secondary PCI Mode. PDC20265: FORCING BURST BIT 0x00 -> 0x01 ACTIVE ide0: BM-DMA at 0x6400-0x6407, BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0x6408-0x640f, BIOS settings: hdc:DMA, hdd:pio PDC20267: IDE controller on PCI bus 00 dev 58 PDC20267: chipset revision 2 PDC20267: not 100% native mode: will probe irqs later PDC20267: (U)DMA Burst Bit ENABLED Primary MASTER Mode Secondary MASTER Mode. PDC20267: neither IDE port enabled (BIOS) ^ This line is interesting I thought... /proc/pci: Bus 0, device 11, function 0: RAID bus controller: Promise Technology, Inc. 20267 (rev 2). IRQ 10. Master Capable. Latency=32. I/O at 0x9400 [0x9407]. I/O at 0x9000 [0x9003]. I/O at 0x8800 [0x8807]. I/O at 0x8400 [0x8403]. I/O at 0x8000 [0x803f]. Non-prefetchable 32 bit memory at 0xd500 [0xd501]. Bus 0, device 17, function 0: Unknown mass storage controller: Promise Technology, Inc. 20265 (rev 2). IRQ 10. Master Capable. Latency=32. I/O at 0x7800 [0x7807]. I/O at 0x7400 [0x7403]. I/O at 0x7000 [0x7007]. I/O at 0x6800 [0x6803]. I/O at 0x6400 [0x643f]. Non-prefetchable 32 bit memory at 0xd480 [0xd481]. /proc/ide/pdc202xx: PDC20265 Chipset. --- General Status Burst Mode : enabled Host Mode: Normal Bus Clocking : 33 PCI Internal IO pad select: 10 mA Status Polling Period: 5 Interrupt Check Status Polling Delay : 7 --- Primary Channel Secondary Channel - enabled enabled 66 Clocking disabled disabled Mode PCI Mode PCI FIFO Empty FIFO Empty --- drive0 - drive1 drive0 -- drive1 -- DMA enabled:no no yes no DMA Mode: NOTSET NOTSET NOTSET NOTSET PIO Mode: NOTSETNOTSET NOTSET NOTSET - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Fasttrak 100 configuration
So I'm trying to get the Promise Fasttrack 100 driver included with 2.4.0-test10 to work on my system. I have 2 45GB drives hooked up in RAID0. I'm trying to install directly onto the drives, but I'm having a couple problems. It seems to detect the controller card and the drives, but they are not assigned to any devices. Any suggestions? Thanks, --James Lamanna Here is some info: dmesg: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PDC20265: IDE controller on PCI bus 00 dev 88 PDC20265: chipset revision 2 PDC20265: not 100% native mode: will probe irqs later PDC20265: (U)DMA Burst Bit DISABLED Primary PCI Mode Secondary PCI Mode. PDC20265: FORCING BURST BIT 0x00 -> 0x01 ACTIVE ide0: BM-DMA at 0x6400-0x6407, BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0x6408-0x640f, BIOS settings: hdc:DMA, hdd:pio PDC20267: IDE controller on PCI bus 00 dev 58 PDC20267: chipset revision 2 PDC20267: not 100% native mode: will probe irqs later PDC20267: (U)DMA Burst Bit ENABLED Primary MASTER Mode Secondary MASTER Mode. PDC20267: neither IDE port enabled (BIOS) ^ This line is interesting I thought... /proc/pci: Bus 0, device 11, function 0: RAID bus controller: Promise Technology, Inc. 20267 (rev 2). IRQ 10. Master Capable. Latency=32. I/O at 0x9400 [0x9407]. I/O at 0x9000 [0x9003]. I/O at 0x8800 [0x8807]. I/O at 0x8400 [0x8403]. I/O at 0x8000 [0x803f]. Non-prefetchable 32 bit memory at 0xd500 [0xd501]. Bus 0, device 17, function 0: Unknown mass storage controller: Promise Technology, Inc. 20265 (rev 2). IRQ 10. Master Capable. Latency=32. I/O at 0x7800 [0x7807]. I/O at 0x7400 [0x7403]. I/O at 0x7000 [0x7007]. I/O at 0x6800 [0x6803]. I/O at 0x6400 [0x643f]. Non-prefetchable 32 bit memory at 0xd480 [0xd481]. /proc/ide/pdc202xx: PDC20265 Chipset. --- General Status Burst Mode : enabled Host Mode: Normal Bus Clocking : 33 PCI Internal IO pad select: 10 mA Status Polling Period: 5 Interrupt Check Status Polling Delay : 7 --- Primary Channel Secondary Channel - enabled enabled 66 Clocking disabled disabled Mode PCI Mode PCI FIFO Empty FIFO Empty --- drive0 - drive1 drive0 -- drive1 -- DMA enabled:no no yes no DMA Mode: NOTSET NOTSET NOTSET NOTSET PIO Mode: NOTSETNOTSET NOTSET NOTSET - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Fasttrak100 questions...
So, I have a system that has 2 45GB IDE drives connected up to a Promise Technologies Fasttrack 100. Promise Techonologies currently has a driver that you can compile against a 2.2 kernel into a module, but it also includes one proprietary object file. During my linux installation I was able to preload the module and have it detect the drives fine as a scsi device, so I was able to install the base system onto them. The question is, is there a way to compile this module into the kernel so that it will automatically detect the card? A simple linking of the module into the scsi library by editing the Makefile doesn't seem to do it. It doesn't detect the drives if I boot off of a floppy with this kernel on it. Also, is it possible for Lilo to even boot this without a RAM disk somewhere? I guess Lilo has to know about the drive, but it can't know without the module...so am I screwed into using floppies with a RAM disk image anyways? Thanks, --James Lamanna - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
