Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Matthew Garrett <[EMAIL PROTECTED]> writes: > On Thu, Jul 05, 2007 at 04:09:24PM +0200, Rafael J. Wysocki wrote: >> On Thursday, 5 July 2007 15:46, Matthew Garrett wrote: >> > I have a model for STD that avoids the need to freeze the entirity of >> > userspace, but I need to find some more time to flesh it out. >> >> You can just describe it, as far as I'm concerned. :-) > > The basic model is that nobody's really described a use-case where we > actually care about restoring system state. What people want is to be > able to restore application state. So, arguably, what we want isn't to > save the entire kernel state and application state in one go because we > can reconstruct a huge amount of that afterwards. [...] > I've mocked up a basic implementation using cryopid, but it's somewhat > limited by the lack of support for sockets. I'd like to move more of > the smarts into the kernel (Hurray, checkpointing!) and then see how > much hardware support ends up horifically broken. You might want to look at the checkpoint / migration support in the OpenVZ kernel in relation to this. That does work to dump the state of a running "virtual environment" complete with applications to disk, move it to another running kernel and restore the content. That might, perhaps, help with the prototype of this? Regards, Daniel - 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: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Matthew Garrett [EMAIL PROTECTED] writes: On Thu, Jul 05, 2007 at 04:09:24PM +0200, Rafael J. Wysocki wrote: On Thursday, 5 July 2007 15:46, Matthew Garrett wrote: I have a model for STD that avoids the need to freeze the entirity of userspace, but I need to find some more time to flesh it out. You can just describe it, as far as I'm concerned. :-) The basic model is that nobody's really described a use-case where we actually care about restoring system state. What people want is to be able to restore application state. So, arguably, what we want isn't to save the entire kernel state and application state in one go because we can reconstruct a huge amount of that afterwards. [...] I've mocked up a basic implementation using cryopid, but it's somewhat limited by the lack of support for sockets. I'd like to move more of the smarts into the kernel (Hurray, checkpointing!) and then see how much hardware support ends up horifically broken. You might want to look at the checkpoint / migration support in the OpenVZ kernel in relation to this. That does work to dump the state of a running virtual environment complete with applications to disk, move it to another running kernel and restore the content. That might, perhaps, help with the prototype of this? Regards, Daniel - 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: Back to the future.
Olivier Galibert <[EMAIL PROTECTED]> writes: > On Fri, Apr 27, 2007 at 06:50:56AM +1000, Nigel Cunningham wrote: > >> I'm perfectly willing to think through some alternate approach if you >> suggest something or prod my thinking in a new direction, but I'm >> afraid I just can't see right now how we can achieve what you're >> after. > > Ok, what about this approach I've been mulling about for a while: > > Suspend-to-disk is pretty much an exercise in state saving. There are > multiple ways to do state saving, but they tend to end up in two > categories: implicit and explicit. [...] > In explicit state saving each object saves what is needed from its > state to an independently defined format (instead of "whatever the > memory organization happens to be at that point"). When reloading the > state you have to parse it, and it usually requires > rebuilding/relocating all references/pointers/etc. If you are looking seriously at this you might want to start with the code in the OpenVZ kernel (http://openvz.org) that allows a VE to "checkpoint" to disk and "restore" on the same or a different machine. This is, as far as I can tell, a portable implementation of this that already handles real live userspace applications moving transparently between two machines. It has the advantage that it lives in an orderly world where most devices and the file system are virtual but, hey, it works right now. Regards, Daniel -- Digital Infrastructure Solutions -- making IT simple, stable and secure Phone: 0401 155 707email: [EMAIL PROTECTED] http://digital-infrastructure.com.au/ - 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: Back to the future.
Olivier Galibert [EMAIL PROTECTED] writes: On Fri, Apr 27, 2007 at 06:50:56AM +1000, Nigel Cunningham wrote: I'm perfectly willing to think through some alternate approach if you suggest something or prod my thinking in a new direction, but I'm afraid I just can't see right now how we can achieve what you're after. Ok, what about this approach I've been mulling about for a while: Suspend-to-disk is pretty much an exercise in state saving. There are multiple ways to do state saving, but they tend to end up in two categories: implicit and explicit. [...] In explicit state saving each object saves what is needed from its state to an independently defined format (instead of whatever the memory organization happens to be at that point). When reloading the state you have to parse it, and it usually requires rebuilding/relocating all references/pointers/etc. If you are looking seriously at this you might want to start with the code in the OpenVZ kernel (http://openvz.org) that allows a VE to checkpoint to disk and restore on the same or a different machine. This is, as far as I can tell, a portable implementation of this that already handles real live userspace applications moving transparently between two machines. It has the advantage that it lives in an orderly world where most devices and the file system are virtual but, hey, it works right now. Regards, Daniel -- Digital Infrastructure Solutions -- making IT simple, stable and secure Phone: 0401 155 707email: [EMAIL PROTECTED] http://digital-infrastructure.com.au/ - 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/
AIC79XX abort -- hardware fault?
G'day. One of the machines I maintain is having real trouble with the AIC79XX HBA or the tape drive attached to it. I believe this is a hardware fault, but I am not certain where the problem lies. Normally I would blame the cable or, maybe, the tape drive, but the early stage of the fault and the reported SCSI driver state make me wonder if this is perhaps an HBA fault? Regards, Daniel scsi0 : Adaptec AIC79XX PCI-X SCSI HBA DRIVER, Rev 3.0 aic7901: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs target0:0:0: asynchronous scsi 0:0:0:0: Attempting to queue an ABORT message:CDB: 0x12 0x0 0x0 0x0 0x24 0x0 scsi0: At time of recovery, card was not paused >> Dump Card State Begins < scsi0: Dumping Card State at program address 0x1b1 Mode 0x11 Card was paused INTSTAT[0x0] SELOID[0x0] SELID[0x0] HS_MAILBOX[0x0] INTCTL[0x0] SEQINTSTAT[0x0] SAVED_MODE[0x0] DFFSTAT[0x19] SCSISIGI[0xa4] SCSIPHASE[0x0] SCSIBUS[0x0] LASTPHASE[0xa0] 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[0x0] SSTAT2[0x0] SSTAT3[0x0] PERRDIAG[0xc0] SIMODE1[0xac] LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x0] LQOSTAT0[0x0] LQOSTAT1[0x0] LQOSTAT2[0x0] SCB Count = 4 CMDS_PENDING = 1 LASTSCB 0x CURRSCB 0x3 NEXTSCB 0x0 qinstart = 1 qinfifonext = 1 QINFIFO: WAITING_TID_QUEUES: Pending list: 3 FIFO_USE[0x0] SCB_CONTROL[0x40] SCB_SCSIID[0x7] 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[0x0] MDFFSTAT[0x5] SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10] scsi0: FIFO1 Active, LONGJMP == 0x8063, SCB 0x3 SEQIMODE[0x3f] SEQINTSRC[0x0] DFCNTRL[0x4] DFSTATUS[0x89] SG_CACHE_SHADOW[0x2] SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x14] SHADDR = 0x06, 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 = 0x0, LQOSTATE = 0x0, OPTIONMODE = 0x52 scsi0: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x0 scsi0: SAVED_SCSIID = 0x0 SAVED_LUN = 0x0 SIMODE0[0xc] CCSCBCTL[0x4] scsi0: REG0 == 0x3, SINDEX = 0x1e0, DINDEX = 0xe1 scsi0: SCBPTR == 0x3, SCB_NEXT == 0xffc0, SCB_NEXT2 == 0xffed CDB 12 0 0 0 24 0 STACK: 0x121 0x0 0x0 0x0 0x0 0x0 0x0 0x0 < Dump Card State Ends >> scsi 0:0:0:0: Device is active, asserting ATN scsi0: Recovery code sleeping scsi0: Timer Expired (active 1) Recovery code awake scsi0: Command abort returning 0x2003 scsi 0:0:0:0: Attempting to queue a TARGET RESET message:CDB: 0x12 0x0 0x0 0x0 0x24 0x 0 scsi0: Device reset code sleeping scsi0: Device reset timer expired (active 2) scsi0: Device reset returning 0x2003 Recovery SCB completes Recovery SCB completes scsi 0:0:0:0: Attempting to queue an ABORT message:CDB: 0x0 0x0 0x0 0x0 0x0 0x0 scsi0: At time of recovery, card was not paused >> Dump Card State Begins < scsi0: Dumping Card State at program address 0x1b2 Mode 0x11 Card was paused INTSTAT[0x0] SELOID[0x0] SELID[0x0] HS_MAILBOX[0x0] INTCTL[0x0] SEQINTSTAT[0x0] SAVED_MODE[0x0] DFFSTAT[0x19] SCSISIGI[0xa4] SCSIPHASE[0x0] SCSIBUS[0x0] LASTPHASE[0xa0] 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[0x0] SSTAT2[0x0] SSTAT3[0x0] PERRDIAG[0xc0] SIMODE1[0xac] LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x0] LQOSTAT0[0x0] LQOSTAT1[0x0] LQOSTAT2[0x0] SCB Count = 4 CMDS_PENDING = 1 LASTSCB 0x CURRSCB 0x3 NEXTSCB 0x0 qinstart = 2 qinfifonext = 2 QINFIFO: WAITING_TID_QUEUES: Pending list: 3 FIFO_USE[0x0] SCB_CONTROL[0x40] SCB_SCSIID[0x7] 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[0x0] MDFFSTAT[0x5] SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10] scsi0: FIFO1 Active, LONGJMP == 0x8063, SCB 0x3 SEQIMODE[0x3f] SEQINTSRC[0x0] DFCNTRL[0x4] DFSTATUS[0x89] SG_CACHE_SHADOW[0x2] SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x14] SHADDR = 0x06, 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 = 0x0, LQOSTATE = 0x0, OPTIONMODE = 0x52 scsi0: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x0 scsi0: SAVED_SCSIID = 0x0 SAVED_LUN = 0x0
AIC79XX abort -- hardware fault?
G'day. One of the machines I maintain is having real trouble with the AIC79XX HBA or the tape drive attached to it. I believe this is a hardware fault, but I am not certain where the problem lies. Normally I would blame the cable or, maybe, the tape drive, but the early stage of the fault and the reported SCSI driver state make me wonder if this is perhaps an HBA fault? Regards, Daniel scsi0 : Adaptec AIC79XX PCI-X SCSI HBA DRIVER, Rev 3.0 Adaptec 29320ALP Ultra320 SCSI adapter aic7901: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs target0:0:0: asynchronous scsi 0:0:0:0: Attempting to queue an ABORT message:CDB: 0x12 0x0 0x0 0x0 0x24 0x0 scsi0: At time of recovery, card was not paused Dump Card State Begins scsi0: Dumping Card State at program address 0x1b1 Mode 0x11 Card was paused INTSTAT[0x0] SELOID[0x0] SELID[0x0] HS_MAILBOX[0x0] INTCTL[0x0] SEQINTSTAT[0x0] SAVED_MODE[0x0] DFFSTAT[0x19] SCSISIGI[0xa4] SCSIPHASE[0x0] SCSIBUS[0x0] LASTPHASE[0xa0] 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[0x0] SSTAT2[0x0] SSTAT3[0x0] PERRDIAG[0xc0] SIMODE1[0xac] LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x0] LQOSTAT0[0x0] LQOSTAT1[0x0] LQOSTAT2[0x0] SCB Count = 4 CMDS_PENDING = 1 LASTSCB 0x CURRSCB 0x3 NEXTSCB 0x0 qinstart = 1 qinfifonext = 1 QINFIFO: WAITING_TID_QUEUES: Pending list: 3 FIFO_USE[0x0] SCB_CONTROL[0x40] SCB_SCSIID[0x7] 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[0x0] MDFFSTAT[0x5] SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10] scsi0: FIFO1 Active, LONGJMP == 0x8063, SCB 0x3 SEQIMODE[0x3f] SEQINTSRC[0x0] DFCNTRL[0x4] DFSTATUS[0x89] SG_CACHE_SHADOW[0x2] SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x14] SHADDR = 0x06, 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 = 0x0, LQOSTATE = 0x0, OPTIONMODE = 0x52 scsi0: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x0 scsi0: SAVED_SCSIID = 0x0 SAVED_LUN = 0x0 SIMODE0[0xc] CCSCBCTL[0x4] scsi0: REG0 == 0x3, SINDEX = 0x1e0, DINDEX = 0xe1 scsi0: SCBPTR == 0x3, SCB_NEXT == 0xffc0, SCB_NEXT2 == 0xffed CDB 12 0 0 0 24 0 STACK: 0x121 0x0 0x0 0x0 0x0 0x0 0x0 0x0 Dump Card State Ends scsi 0:0:0:0: Device is active, asserting ATN scsi0: Recovery code sleeping scsi0: Timer Expired (active 1) Recovery code awake scsi0: Command abort returning 0x2003 scsi 0:0:0:0: Attempting to queue a TARGET RESET message:CDB: 0x12 0x0 0x0 0x0 0x24 0x 0 scsi0: Device reset code sleeping scsi0: Device reset timer expired (active 2) scsi0: Device reset returning 0x2003 Recovery SCB completes Recovery SCB completes scsi 0:0:0:0: Attempting to queue an ABORT message:CDB: 0x0 0x0 0x0 0x0 0x0 0x0 scsi0: At time of recovery, card was not paused Dump Card State Begins scsi0: Dumping Card State at program address 0x1b2 Mode 0x11 Card was paused INTSTAT[0x0] SELOID[0x0] SELID[0x0] HS_MAILBOX[0x0] INTCTL[0x0] SEQINTSTAT[0x0] SAVED_MODE[0x0] DFFSTAT[0x19] SCSISIGI[0xa4] SCSIPHASE[0x0] SCSIBUS[0x0] LASTPHASE[0xa0] 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[0x0] SSTAT2[0x0] SSTAT3[0x0] PERRDIAG[0xc0] SIMODE1[0xac] LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x0] LQOSTAT0[0x0] LQOSTAT1[0x0] LQOSTAT2[0x0] SCB Count = 4 CMDS_PENDING = 1 LASTSCB 0x CURRSCB 0x3 NEXTSCB 0x0 qinstart = 2 qinfifonext = 2 QINFIFO: WAITING_TID_QUEUES: Pending list: 3 FIFO_USE[0x0] SCB_CONTROL[0x40] SCB_SCSIID[0x7] 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[0x0] MDFFSTAT[0x5] SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10] scsi0: FIFO1 Active, LONGJMP == 0x8063, SCB 0x3 SEQIMODE[0x3f] SEQINTSRC[0x0] DFCNTRL[0x4] DFSTATUS[0x89] SG_CACHE_SHADOW[0x2] SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x14] SHADDR = 0x06, 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 = 0x0, LQOSTATE = 0x0, OPTIONMODE = 0x52 scsi0: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x0 scsi0: SAVED_SCSIID = 0x0 SAVED_LUN = 0x0 SIMODE0[0xc] CCSCBCTL[0x4] scsi0: REG0 == 0x3, SINDEX = 0x1e0,
Re: Adaptec AHA-2940U2W "Data Parity Error Dectected" messages
Lee Revell <[EMAIL PROTECTED]> writes: > On Tue, 2005-08-09 at 17:19 +1000, Daniel Pittman wrote: >> I recently installed a SCSI tape drive and Adaptec AHA-2940U2W SCSI >> controller into my server to run backups. >> >> Since then, the driver issues these warnings on a semi-regular basis >> while the drive is busy: >> >> Aug 9 17:00:26 anu kernel: scsi0: Data Parity Error Detected during address >> or write data phase >> Aug 9 17:00:26 anu kernel: scsi0: PCI error Interrupt at seqaddr = 0x8 > > Make sure the hardware is all installed correctly. Check that the card > is fully seated, or try it in another PCI slot. Thanks. I will take the server down shortly and give that a shot. > Also check your cabling and termination. Could SCSI cabling and/or termination cause the card to report *PCI* errors, or am I misunderstanding these messages? I guess that the fact that the "PCI" bit kept showing up in them is what confuses me. I didn't except a SCSI card to report PCI bus issues through the Linux driver, and since it claimed to be a victim, not a cause, I didn't know quite how to trace the problem down... Thanks, Daniel - 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/
Adaptec AHA-2940U2W "Data Parity Error Dectected" messages
I recently installed a SCSI tape drive and Adaptec AHA-2940U2W SCSI controller into my server to run backups. Since then, the driver issues these warnings on a semi-regular basis while the drive is busy: Aug 9 17:00:26 anu kernel: scsi0: Data Parity Error Detected during address or write data phase Aug 9 17:00:26 anu kernel: scsi0: PCI error Interrupt at seqaddr = 0x8 [...] Aug 9 17:03:34 anu kernel: scsi0: Data Parity Error Detected during address or write data phase [...] Aug 9 17:04:36 anu kernel: scsi0: PCI parity error checking has been disabled. Aug 9 17:04:36 anu kernel: scsi0: Some device on this bus is generating bad parity. Aug 9 17:04:36 anu kernel: scsi0: This is an error *observed by*, not *generated by*, this controller. Aug 9 17:04:36 anu kernel: scsi0: Too many PCI parity errors observed as a target. Aug 9 17:04:36 anu kernel: scsi0: WARNING WARNING WARNING WARNING Now, the log message claims that the SCSI controller is not responsible for these parity errors, so my questions are: * should I panic about this? * should I have seen this before the SCSI controller was installed? * can I do anything about it, or identifying the cause? Thanks, Daniel - 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/
Adaptec AHA-2940U2W Data Parity Error Dectected messages
I recently installed a SCSI tape drive and Adaptec AHA-2940U2W SCSI controller into my server to run backups. Since then, the driver issues these warnings on a semi-regular basis while the drive is busy: Aug 9 17:00:26 anu kernel: scsi0: Data Parity Error Detected during address or write data phase Aug 9 17:00:26 anu kernel: scsi0: PCI error Interrupt at seqaddr = 0x8 [...] Aug 9 17:03:34 anu kernel: scsi0: Data Parity Error Detected during address or write data phase [...] Aug 9 17:04:36 anu kernel: scsi0: PCI parity error checking has been disabled. Aug 9 17:04:36 anu kernel: scsi0: Some device on this bus is generating bad parity. Aug 9 17:04:36 anu kernel: scsi0: This is an error *observed by*, not *generated by*, this controller. Aug 9 17:04:36 anu kernel: scsi0: Too many PCI parity errors observed as a target. Aug 9 17:04:36 anu kernel: scsi0: WARNING WARNING WARNING WARNING Now, the log message claims that the SCSI controller is not responsible for these parity errors, so my questions are: * should I panic about this? * should I have seen this before the SCSI controller was installed? * can I do anything about it, or identifying the cause? Thanks, Daniel - 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: Adaptec AHA-2940U2W Data Parity Error Dectected messages
Lee Revell [EMAIL PROTECTED] writes: On Tue, 2005-08-09 at 17:19 +1000, Daniel Pittman wrote: I recently installed a SCSI tape drive and Adaptec AHA-2940U2W SCSI controller into my server to run backups. Since then, the driver issues these warnings on a semi-regular basis while the drive is busy: Aug 9 17:00:26 anu kernel: scsi0: Data Parity Error Detected during address or write data phase Aug 9 17:00:26 anu kernel: scsi0: PCI error Interrupt at seqaddr = 0x8 Make sure the hardware is all installed correctly. Check that the card is fully seated, or try it in another PCI slot. Thanks. I will take the server down shortly and give that a shot. Also check your cabling and termination. Could SCSI cabling and/or termination cause the card to report *PCI* errors, or am I misunderstanding these messages? I guess that the fact that the PCI bit kept showing up in them is what confuses me. I didn't except a SCSI card to report PCI bus issues through the Linux driver, and since it claimed to be a victim, not a cause, I didn't know quite how to trace the problem down... Thanks, Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Updates to Maestro{1,2,2E} driver -- multiple open of dsp, persistent buffers.
STRO_CHANNELS 1 + bool 'Persistent Maestro dsp buffers' CONFIG_MAESTRO_PERSIST +fi dep_tristate ' ESS Maestro3/Allegro driver (EXPERIMENTAL)' CONFIG_SOUND_MAESTRO3 $CONFIG_SOUND $CONFIG_PCI $CONFIG_EXPERIMENTAL dep_tristate ' Intel ICH (i8xx) audio support' CONFIG_SOUND_ICH $CONFIG_PCI dep_tristate ' S3 SonicVibes' CONFIG_SOUND_SONICVIBES $CONFIG_SOUND diff -ru linux/drivers/sound/maestro.c linux.maestro/drivers/sound/maestro.c --- linux/drivers/sound/maestro.c Fri Jul 6 17:16:21 2001 +++ linux.maestro/drivers/sound/maestro.c Thu Jul 5 15:42:42 2001 @@ -1,6 +1,6 @@ /* * - * ESS Maestro/Maestro-2/Maestro-2E driver for Linux 2.[23].x + * ESS Maestro/Maestro-2/Maestro-2E driver for Linux 2.[234].x * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -28,7 +28,7 @@ * proprietors of Hack Central for fine lodging. * * Supported devices: - * /dev/dsp0-3standard /dev/dsp device, (mostly) OSS compatible + * /dev/dspstandard /dev/dsp device, (mostly) OSS compatible * /dev/mixer standard /dev/mixer device, (mostly) OSS compatible * * Hardware Description @@ -39,7 +39,7 @@ * channels. They can take data from a number of sources and perform * basic encodings of the data. The wavecache is a storehouse for * PCM data. Typically it deals with PCI and interracts with the - * APUs. The ASSP is a wacky DSP like device that ESS is loth + * APUs. The ASSP is a wacky DSP like device that ESS is loath * to release docs on. Thankfully it isn't required on the Maestro * until you start doing insane things like FM emulation and surround * encoding. The codecs are almost always AC-97 compliant codecs, @@ -69,20 +69,19 @@ * software. The pass between the 2 APUs is supposedly what requires us * to have a 512 byte buffer sitting around in wavecache/memory. * - * The wavecache makes our life even more fun. First off, it can - * only address the first 28 bits of PCI address space, making it - * useless on quite a few architectures. Secondly, its insane. - * It claims to fetch from 4 regions of PCI space, each 4 meg in length. - * But that doesn't really work. You can only use 1 region. So all our - * allocations have to be in 4meg of each other. Booo. Hiss. - * So we have a module parameter, dsps_order, that is the order of - * the number of dsps to provide. All their buffer space is allocated - * on open time. The sonicvibes OSS routines we inherited really want - * power of 2 buffers, so we have all those next to each other, then - * 512 byte regions for the recording wavecaches. This ends up - * wasting quite a bit of memory. The only fixes I can see would be - * getting a kernel allocator that could work in zones, or figuring out - * just how to coerce the WP into doing what we want. + * The wavecache makes our life even more fun. First off, it can only address + * the first 28 bits of PCI address space, making it useless on quite a + * few architectures. Secondly, its insane. It claims to fetch from 4 + * regions of PCI space, each 4 meg in length. But that doesn't really + * work. You can only use 1 region. So all our allocations have to be in + * 4meg of each other. Booo. Hiss. So we have a module parameter, + * channels, that is the number of dsps to provide. All their buffer + * space is allocated on open time. The sonicvibes OSS routines we + * inherited really want power of 2 buffers, so we have all those next to + * each other, then 512 byte regions for the recording wavecaches. This + * ends up wasting quite a bit of memory. The only fixes I can see would + * be getting a kernel allocator that could work in zones, or figuring + * out just how to coerce the WP into doing what we want. * * The indirection of the various registers means we have to spinlock * nearly all register accesses. We have the main register indirection @@ -115,6 +114,15 @@ * themselves, but we'll see. * * History + * v0.15 - Jul 05 2001 - Daniel Pittman <[EMAIL PROTECTED]> + * Support multiple open of /dev/dsp, not multiple dsp devices. + * Parse the kernel command line for arguments. + * Add module parameter descriptions. + * Added configure time support for setting default number of dsp + * channels to use. This is not the dsps_order value, because that's + * totally, like, impossible to explain to anyone who isn't a math geek. + * Added support for persistent sound buffer allocation for a card so + * that my laptop will still be able to play sound after a compile. * v0.15 - May 21 2001 - Marcus Meissner <[EMAIL PROTECTED]> * Ported to Linux 2.4 PCI API. Some clean ups, global devs list * removed (now using pci device driver data). @@ -246
[PATCH] Updates to Maestro{1,2,2E} driver -- multiple open of dsp, persistent buffers.
'Persistent Maestro dsp buffers' CONFIG_MAESTRO_PERSIST +fi dep_tristate ' ESS Maestro3/Allegro driver (EXPERIMENTAL)' CONFIG_SOUND_MAESTRO3 $CONFIG_SOUND $CONFIG_PCI $CONFIG_EXPERIMENTAL dep_tristate ' Intel ICH (i8xx) audio support' CONFIG_SOUND_ICH $CONFIG_PCI dep_tristate ' S3 SonicVibes' CONFIG_SOUND_SONICVIBES $CONFIG_SOUND diff -ru linux/drivers/sound/maestro.c linux.maestro/drivers/sound/maestro.c --- linux/drivers/sound/maestro.c Fri Jul 6 17:16:21 2001 +++ linux.maestro/drivers/sound/maestro.c Thu Jul 5 15:42:42 2001 @@ -1,6 +1,6 @@ /* * - * ESS Maestro/Maestro-2/Maestro-2E driver for Linux 2.[23].x + * ESS Maestro/Maestro-2/Maestro-2E driver for Linux 2.[234].x * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -28,7 +28,7 @@ * proprietors of Hack Central for fine lodging. * * Supported devices: - * /dev/dsp0-3standard /dev/dsp device, (mostly) OSS compatible + * /dev/dspstandard /dev/dsp device, (mostly) OSS compatible * /dev/mixer standard /dev/mixer device, (mostly) OSS compatible * * Hardware Description @@ -39,7 +39,7 @@ * channels. They can take data from a number of sources and perform * basic encodings of the data. The wavecache is a storehouse for * PCM data. Typically it deals with PCI and interracts with the - * APUs. The ASSP is a wacky DSP like device that ESS is loth + * APUs. The ASSP is a wacky DSP like device that ESS is loath * to release docs on. Thankfully it isn't required on the Maestro * until you start doing insane things like FM emulation and surround * encoding. The codecs are almost always AC-97 compliant codecs, @@ -69,20 +69,19 @@ * software. The pass between the 2 APUs is supposedly what requires us * to have a 512 byte buffer sitting around in wavecache/memory. * - * The wavecache makes our life even more fun. First off, it can - * only address the first 28 bits of PCI address space, making it - * useless on quite a few architectures. Secondly, its insane. - * It claims to fetch from 4 regions of PCI space, each 4 meg in length. - * But that doesn't really work. You can only use 1 region. So all our - * allocations have to be in 4meg of each other. Booo. Hiss. - * So we have a module parameter, dsps_order, that is the order of - * the number of dsps to provide. All their buffer space is allocated - * on open time. The sonicvibes OSS routines we inherited really want - * power of 2 buffers, so we have all those next to each other, then - * 512 byte regions for the recording wavecaches. This ends up - * wasting quite a bit of memory. The only fixes I can see would be - * getting a kernel allocator that could work in zones, or figuring out - * just how to coerce the WP into doing what we want. + * The wavecache makes our life even more fun. First off, it can only address + * the first 28 bits of PCI address space, making it useless on quite a + * few architectures. Secondly, its insane. It claims to fetch from 4 + * regions of PCI space, each 4 meg in length. But that doesn't really + * work. You can only use 1 region. So all our allocations have to be in + * 4meg of each other. Booo. Hiss. So we have a module parameter, + * channels, that is the number of dsps to provide. All their buffer + * space is allocated on open time. The sonicvibes OSS routines we + * inherited really want power of 2 buffers, so we have all those next to + * each other, then 512 byte regions for the recording wavecaches. This + * ends up wasting quite a bit of memory. The only fixes I can see would + * be getting a kernel allocator that could work in zones, or figuring + * out just how to coerce the WP into doing what we want. * * The indirection of the various registers means we have to spinlock * nearly all register accesses. We have the main register indirection @@ -115,6 +114,15 @@ * themselves, but we'll see. * * History + * v0.15 - Jul 05 2001 - Daniel Pittman [EMAIL PROTECTED] + * Support multiple open of /dev/dsp, not multiple dsp devices. + * Parse the kernel command line for arguments. + * Add module parameter descriptions. + * Added configure time support for setting default number of dsp + * channels to use. This is not the dsps_order value, because that's + * totally, like, impossible to explain to anyone who isn't a math geek. + * Added support for persistent sound buffer allocation for a card so + * that my laptop will still be able to play sound after a compile. * v0.15 - May 21 2001 - Marcus Meissner [EMAIL PROTECTED] * Ported to Linux 2.4 PCI API. Some clean ups, global devs list * removed (now using pci device driver data). @@ -246,26 +254,48 @@ #define M_printk(x
Re: What does "NAT: dropping untracked packet" mean?
dmeyer <[EMAIL PROTECTED]> writes: > > In article <[EMAIL PROTECTED]> you write: >> On Thu, 01 Feb 2001, Nils Rennebarth wrote: >> > Feb 1 12:58:56 obelix kernel: NAT: 0 dropping untracked packet >> ce767600 1 129.69.22.21 -> 224.0.0.2 >> >> It means that your box drops multicast administrative packets on the >> floor. > > I'm getting the occasional > > Feb 1 13:17:08 yendi kernel: NAT: 0 dropping untracked packet c3ea4da0 > 1 146.188.249.73 -> 209.220.232.240 > > syslog message. What exactly does it mean? 146.188.249.73 isn't my > machine at all, and 209.220.232.240 is my firewall. I assume I'm > dropping someone's packets on the floor, but what can cause a packet > to get dropped like that? The one big thing I know of that causes these messages is a long-standing bug in the FreeBSD and OpenBSD (and presumably NetBSD, I don't know about that one, though) network stacks. When sending an ICMP host unreachable response to a DF packet, some of the packet was byte-swapped. The bytes were *only* in the segment of the original IP packet appended to the ICMP message for identification purposes. Under normal conditions this packet works fine with Linux. The connection is killed, all is fine. When running netfilter and connection tracking, netfilter uses these byte-swapped fields to associate the ICMP message with the original TCP or UDP packets. Because the fields are out-of-order, this match fails. netfilter then drops the packet on the floor and generates the 'untracked packet' message. FreeBSD have fixes their network stack not that long ago. I believe that their 5.0 release corrects the bug, but I am not sure of that. Check with them if you really care. I don't believe that OpenBSD have corrected this problem at this stage but, again, I have not checked recently. Check with them if you really care. This bug is *only* triggered when the packet has DF set. Normal packets don't trigger that particular buggy code path. Daniel -- The truth knocks on the door and you say, 'Go away, I'm looking for the truth,' and so it goes away. Puzzling... -- Robert Pirsig - 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: What does NAT: dropping untracked packet mean?
dmeyer [EMAIL PROTECTED] writes: In article [EMAIL PROTECTED] you write: On Thu, 01 Feb 2001, Nils Rennebarth wrote: Feb 1 12:58:56 obelix kernel: NAT: 0 dropping untracked packet ce767600 1 129.69.22.21 - 224.0.0.2 It means that your box drops multicast administrative packets on the floor. I'm getting the occasional Feb 1 13:17:08 yendi kernel: NAT: 0 dropping untracked packet c3ea4da0 1 146.188.249.73 - 209.220.232.240 syslog message. What exactly does it mean? 146.188.249.73 isn't my machine at all, and 209.220.232.240 is my firewall. I assume I'm dropping someone's packets on the floor, but what can cause a packet to get dropped like that? The one big thing I know of that causes these messages is a long-standing bug in the FreeBSD and OpenBSD (and presumably NetBSD, I don't know about that one, though) network stacks. When sending an ICMP host unreachable response to a DF packet, some of the packet was byte-swapped. The bytes were *only* in the segment of the original IP packet appended to the ICMP message for identification purposes. Under normal conditions this packet works fine with Linux. The connection is killed, all is fine. When running netfilter and connection tracking, netfilter uses these byte-swapped fields to associate the ICMP message with the original TCP or UDP packets. Because the fields are out-of-order, this match fails. netfilter then drops the packet on the floor and generates the 'untracked packet' message. FreeBSD have fixes their network stack not that long ago. I believe that their 5.0 release corrects the bug, but I am not sure of that. Check with them if you really care. I don't believe that OpenBSD have corrected this problem at this stage but, again, I have not checked recently. Check with them if you really care. This bug is *only* triggered when the packet has DF set. Normal packets don't trigger that particular buggy code path. Daniel -- The truth knocks on the door and you say, 'Go away, I'm looking for the truth,' and so it goes away. Puzzling... -- Robert Pirsig - 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/
[PATCH] Maestro 2 sound driver update.
; = "y" -o "$CONFIG_SOUND_MAESTRO" = "m" ]; then + int 'Number of channels (1,2,4)' CONFIG_MAESTRO_CHANNELS 1 + bool 'Persistent Maestro dsp buffers' CONFIG_MAESTRO_PERSIST +fi dep_tristate ' S3 SonicVibes' CONFIG_SOUND_SONICVIBES $CONFIG_SOUND if [ "$CONFIG_VISWS" = "y" ]; then dep_tristate ' SGI Visual Workstation Sound' CONFIG_SOUND_VWSND $CONFIG_SOUND Only in linux.dp/drivers/sound: Config.in~ diff -u --recursive linux/drivers/sound/maestro.c linux.dp/drivers/sound/maestro.c --- linux/drivers/sound/maestro.c Tue Dec 12 15:17:44 2000 +++ linux.dp/drivers/sound/maestro.c Tue Dec 12 14:58:45 2000 @@ -1,6 +1,6 @@ /* * - * ESS Maestro/Maestro-2/Maestro-2E driver for Linux 2.[23].x + * ESS Maestro/Maestro-2/Maestro-2E driver for Linux 2.[234].x * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -28,7 +28,7 @@ * proprietors of Hack Central for fine lodging. * * Supported devices: - * /dev/dsp0-3standard /dev/dsp device, (mostly) OSS compatible + * /dev/dspstandard /dev/dsp device, (mostly) OSS compatible * /dev/mixer standard /dev/mixer device, (mostly) OSS compatible * * Hardware Description @@ -39,7 +39,7 @@ * channels. They can take data from a number of sources and perform * basic encodings of the data. The wavecache is a storehouse for * PCM data. Typically it deals with PCI and interracts with the - * APUs. The ASSP is a wacky DSP like device that ESS is loth + * APUs. The ASSP is a wacky DSP like device that ESS is loath * to release docs on. Thankfully it isn't required on the Maestro * until you start doing insane things like FM emulation and surround * encoding. The codecs are almost always AC-97 compliant codecs, @@ -69,20 +69,19 @@ * software. The pass between the 2 APUs is supposedly what requires us * to have a 512 byte buffer sitting around in wavecache/memory. * - * The wavecache makes our life even more fun. First off, it can - * only address the first 28 bits of PCI address space, making it - * useless on quite a few architectures. Secondly, its insane. - * It claims to fetch from 4 regions of PCI space, each 4 meg in length. - * But that doesn't really work. You can only use 1 region. So all our - * allocations have to be in 4meg of each other. Booo. Hiss. - * So we have a module parameter, dsps_order, that is the order of - * the number of dsps to provide. All their buffer space is allocated - * on open time. The sonicvibes OSS routines we inherited really want - * power of 2 buffers, so we have all those next to each other, then - * 512 byte regions for the recording wavecaches. This ends up - * wasting quite a bit of memory. The only fixes I can see would be - * getting a kernel allocator that could work in zones, or figuring out - * just how to coerce the WP into doing what we want. + * The wavecache makes our life even more fun. First off, it can only address + * the first 28 bits of PCI address space, making it useless on quite a + * few architectures. Secondly, its insane. It claims to fetch from 4 + * regions of PCI space, each 4 meg in length. But that doesn't really + * work. You can only use 1 region. So all our allocations have to be in + * 4meg of each other. Booo. Hiss. So we have a module parameter, + * channels, that is the number of dsps to provide. All their buffer + * space is allocated on open time. The sonicvibes OSS routines we + * inherited really want power of 2 buffers, so we have all those next to + * each other, then 512 byte regions for the recording wavecaches. This + * ends up wasting quite a bit of memory. The only fixes I can see would + * be getting a kernel allocator that could work in zones, or figuring + * out just how to coerce the WP into doing what we want. * * The indirection of the various registers means we have to spinlock * nearly all register accesses. We have the main register indirection @@ -115,6 +114,16 @@ * themselves, but we'll see. * * History + * v0.16 - Sep 20 2000 - Daniel Pittman <[EMAIL PROTECTED]> + * Support multiple open of /dev/dsp, not multiple dsp devices. + * Parse the kernel command line for arguments. + * Add module parameter descriptions. + * v0.15 - Sep 14 2000 - Daniel Pittman <[EMAIL PROTECTED]> + * Added configure time support for setting default number of dsp + * channels to use. This is not the dsps_order value, because that's + * totally, like, impossible to explain to anyone who isn't a math geek. + * Added support for persistent sound buffer allocation for a card so + * that my laptop will still be able to play sound after a compile. * (still kind of v
[PATCH] Maestro 2 sound driver update.
+if [ "$CONFIG_SOUND_MAESTRO" = "y" -o "$CONFIG_SOUND_MAESTRO" = "m" ]; then + int 'Number of channels (1,2,4)' CONFIG_MAESTRO_CHANNELS 1 + bool 'Persistent Maestro dsp buffers' CONFIG_MAESTRO_PERSIST +fi dep_tristate ' S3 SonicVibes' CONFIG_SOUND_SONICVIBES $CONFIG_SOUND if [ "$CONFIG_VISWS" = "y" ]; then dep_tristate ' SGI Visual Workstation Sound' CONFIG_SOUND_VWSND $CONFIG_SOUND Only in linux.dp/drivers/sound: Config.in~ diff -u --recursive linux/drivers/sound/maestro.c linux.dp/drivers/sound/maestro.c --- linux/drivers/sound/maestro.c Tue Dec 12 15:17:44 2000 +++ linux.dp/drivers/sound/maestro.c Tue Dec 12 14:58:45 2000 @@ -1,6 +1,6 @@ /* * - * ESS Maestro/Maestro-2/Maestro-2E driver for Linux 2.[23].x + * ESS Maestro/Maestro-2/Maestro-2E driver for Linux 2.[234].x * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -28,7 +28,7 @@ * proprietors of Hack Central for fine lodging. * * Supported devices: - * /dev/dsp0-3standard /dev/dsp device, (mostly) OSS compatible + * /dev/dspstandard /dev/dsp device, (mostly) OSS compatible * /dev/mixer standard /dev/mixer device, (mostly) OSS compatible * * Hardware Description @@ -39,7 +39,7 @@ * channels. They can take data from a number of sources and perform * basic encodings of the data. The wavecache is a storehouse for * PCM data. Typically it deals with PCI and interracts with the - * APUs. The ASSP is a wacky DSP like device that ESS is loth + * APUs. The ASSP is a wacky DSP like device that ESS is loath * to release docs on. Thankfully it isn't required on the Maestro * until you start doing insane things like FM emulation and surround * encoding. The codecs are almost always AC-97 compliant codecs, @@ -69,20 +69,19 @@ * software. The pass between the 2 APUs is supposedly what requires us * to have a 512 byte buffer sitting around in wavecache/memory. * - * The wavecache makes our life even more fun. First off, it can - * only address the first 28 bits of PCI address space, making it - * useless on quite a few architectures. Secondly, its insane. - * It claims to fetch from 4 regions of PCI space, each 4 meg in length. - * But that doesn't really work. You can only use 1 region. So all our - * allocations have to be in 4meg of each other. Booo. Hiss. - * So we have a module parameter, dsps_order, that is the order of - * the number of dsps to provide. All their buffer space is allocated - * on open time. The sonicvibes OSS routines we inherited really want - * power of 2 buffers, so we have all those next to each other, then - * 512 byte regions for the recording wavecaches. This ends up - * wasting quite a bit of memory. The only fixes I can see would be - * getting a kernel allocator that could work in zones, or figuring out - * just how to coerce the WP into doing what we want. + * The wavecache makes our life even more fun. First off, it can only address + * the first 28 bits of PCI address space, making it useless on quite a + * few architectures. Secondly, its insane. It claims to fetch from 4 + * regions of PCI space, each 4 meg in length. But that doesn't really + * work. You can only use 1 region. So all our allocations have to be in + * 4meg of each other. Booo. Hiss. So we have a module parameter, + * channels, that is the number of dsps to provide. All their buffer + * space is allocated on open time. The sonicvibes OSS routines we + * inherited really want power of 2 buffers, so we have all those next to + * each other, then 512 byte regions for the recording wavecaches. This + * ends up wasting quite a bit of memory. The only fixes I can see would + * be getting a kernel allocator that could work in zones, or figuring + * out just how to coerce the WP into doing what we want. * * The indirection of the various registers means we have to spinlock * nearly all register accesses. We have the main register indirection @@ -115,6 +114,16 @@ * themselves, but we'll see. * * History + * v0.16 - Sep 20 2000 - Daniel Pittman [EMAIL PROTECTED] + * Support multiple open of /dev/dsp, not multiple dsp devices. + * Parse the kernel command line for arguments. + * Add module parameter descriptions. + * v0.15 - Sep 14 2000 - Daniel Pittman [EMAIL PROTECTED] + * Added configure time support for setting default number of dsp + * channels to use. This is not the dsps_order value, because that's + * totally, like, impossible to explain to anyone who isn't a math geek. + * Added support for persistent sound buffer allocation for a card so + * that my laptop will still be able to play sound after a compile. * (stil
