[PATCH: 2nd try] PS/2 ESDI
All,
OK, here is the corrected patch as promised. I have placed it in the same
location as the previous one in case the mailer mangles it.
http://www.sound.net/~hald/projects/ps2esdi/ps2esdi-2.4.3.patch0
Thanks, and not on the list,
Hal Duston
[EMAIL PROTECTED]
Bring ps2esdi driver up to date with current block device architecture.
Make it boot.
Change nr_sectors to current_nr_sectors.
Remove recursion.
Remove sleep_on.
Add spinlock to ISR and call end_request from there.
--- linux-2.4.3/drivers/block/ps2esdi.c Fri Oct 27 01:35:47 2000
+++ linux-2.4.3-hdd0/drivers/block/ps2esdi.cTue Apr 10 00:50:26 2001
@@ -89,8 +89,6 @@
static void ps2esdi_initial_reset_int_handler(u_int);
static void ps2esdi_geometry_int_handler(u_int);
-static void ps2esdi_continue_request(void);
-
static int ps2esdi_open(struct inode *inode, struct file *file);
static int ps2esdi_release(struct inode *inode, struct file *file);
@@ -469,29 +467,26 @@
DEVICE_NAME,
CURRENT_DEV, MINOR(CURRENT->rq_dev),
CURRENT->cmd, CURRENT->sector,
- CURRENT->nr_sectors, CURRENT->buffer);
+ CURRENT->current_nr_sectors, CURRENT->buffer);
#endif
/* standard macro that ensures that requests are really on the
list + sanity checks. */
INIT_REQUEST;
- if (virt_to_bus(CURRENT->buffer + CURRENT->nr_sectors * 512) > 16 * MB) {
+ if (virt_to_bus(CURRENT->buffer + CURRENT->current_nr_sectors * 512) > 16 *
+MB) {
printk("%s: DMA above 16MB not supported\n", DEVICE_NAME);
end_request(FAIL);
- if (!QUEUE_EMPTY)
- do_ps2esdi_request(q);
- return;
} /* check for above 16Mb dmas */
- if ((CURRENT_DEV < ps2esdi_drives) &&
- (CURRENT->sector + CURRENT->nr_sectors <=
+ else if ((CURRENT_DEV < ps2esdi_drives) &&
+ (CURRENT->sector + CURRENT->current_nr_sectors <=
ps2esdi[MINOR(CURRENT->rq_dev)].nr_sects)) {
#if 0
printk("%s:got request. device : %d minor : %d command : %d sector :
%ld count : %ld\n",
DEVICE_NAME,
- CURRENT_DEV, MINOR(CURRENT->dev),
+ CURRENT_DEV, MINOR(CURRENT->rq_dev),
CURRENT->cmd, CURRENT->sector,
- CURRENT->nr_sectors);
+ CURRENT->current_nr_sectors);
#endif
@@ -500,21 +495,17 @@
#if 0
printk("%s: blocknumber : %d\n", DEVICE_NAME, block);
#endif
- count = CURRENT->nr_sectors;
+ count = CURRENT->current_nr_sectors;
switch (CURRENT->cmd) {
case READ:
ps2esdi_readwrite(READ, CURRENT_DEV, block, count);
- return;
break;
case WRITE:
ps2esdi_readwrite(WRITE, CURRENT_DEV, block, count);
- return;
break;
default:
printk("%s: Unknown command\n", DEVICE_NAME);
end_request(FAIL);
- if (!QUEUE_EMPTY)
- do_ps2esdi_request(q);
break;
} /* handle different commands */
}
@@ -523,8 +514,6 @@
printk("Grrr. error. ps2esdi_drives: %d, %lu %lu\n", ps2esdi_drives,
CURRENT->sector, ps2esdi[MINOR(CURRENT->rq_dev)].nr_sects);
end_request(FAIL);
- if (!QUEUE_EMPTY)
- do_ps2esdi_request(q);
}
} /* main strategy routine */
@@ -570,8 +559,6 @@
u_short cmd_blk[TYPE_1_CMD_BLK_LENGTH];
/* do some relevant arithmatic */
- CURRENT->current_nr_sectors =
- (count < (2 * MAX_16BIT / SECT_SIZE)) ? count : (2 * MAX_16BIT /
SECT_SIZE);
track = block / ps2esdi_info[drive].sect;
head = track % ps2esdi_info[drive].head;
cylinder = track / ps2esdi_info[drive].head;
@@ -590,13 +577,8 @@
/* send the command block to the controller */
if (ps2esdi_out_cmd_blk(cmd_blk)) {
printk("%s: Controller failed\n", DEVICE_NAME);
- if ((++CURRENT->errors) < MAX_RETRIES)
- return do_ps2esdi_request(NULL);
- else {
+ if ((++CURRENT->errors) >= MAX_RETRIES)
end_request(FAIL);
- if (!QUEUE_EMPTY)
- do_ps2esdi_request(NULL);
- }
}
/* check for failure to put out the command block */
else {
@@ -680,7 +662,7 @@
buffer=(char
Re: skb allocation problems
On Mon, Apr 09, 2001 at 07:03:46PM +0300, [EMAIL PROTECTED] wrote:
> I have written a test module which closely mirrors what my code tries to
> do(attached below). This is what i get:
>
> PRE_R: old skb:c371ee40 new skb:c371ee30
I guess oldskb->len is <=0xc, and the slab allocator packs them near together
in the same zone.
> printk("\nPRE_R: old skb:%p", (*pskb)->data);
>
> /* translation happens in the real code here */
>
> skb = alloc_skb((*pskb)->len, GFP_ATOMIC);
> if(!skb)
> printk("alloc failed");
I guess you want a return here.
> skb_reserve(skb, 16);
You cannot do that if you didn't make sure that the old skb had enough
room for it (or rather it'll sometimes panic)
-Andi
-
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: No 100 HZ timer !
On Mon, Apr 09, 2001 at 02:19:28PM -0400, Mark Salisbury wrote: > this is one of linux biggest weaknesses. the fixed interval timer is a > throwback. it should be replaced with a variable interval timer with interrupts > on demand for any system with a cpu sane/modern enough to have an on-chip > interrupting decrementer. (i.e just about any modern chip) Just how would you do kernel/user CPU time accounting then ? It's currently done on every timer tick, and doing it less often would make it useless. -Andi - 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: rw_semaphores
On Tue, 10 Apr 2001, Tachino Nobuhiro wrote: > > I am not familiar with semaphore or x86, so this may not be correct, > but if the following sequence is possible, the writer can call wake_up() > before the reader calls add_wait_queue() and reader may sleep forever. > Is it possible? The ordering is certainly possible, but if it happens, __down_read_failed() won't actually sleep, because it will notice that the value is positive and just return immediately. So it will do some unnecessary work (add itself to the wait-queue only to remove itself immediately again), but it will do the right thing. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sources of entropy - /dev/random problem for network servers
On Mon, Apr 09, 2001 at 01:04:47PM +0200, Heusden, Folkert van wrote: > >> However, only 3 drivers in drivers/net actually set > >> SA_SAMPLE_RANDOM when calling request_irq(). I believe > >> all of them should. > > No, because an attacker can potentially control input and make it > > non-random. > AB> 2. Given that otherwise in at least my application (and machine > AB> without keyboard and mouse can't be too uncommon) there is *no* > AB> entropy otherwise, which is rather easier for a hacker. At least > > Put a soundcard in your system and install audio-entropyd. > Works pretty nice. Do you know where to find it? Freshmeat has a listing, but it's pointing to mindrot.org and is 404 not found. -- Ferret - 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/
Ethernet driver
Hi everybody, I want to put some filter condition on ethernet driver in Promiscuous mode so as it allow packets to IP stack having Virtual mac address existing in say some Dynamic list.Can anybody help how can I do it. I am using eepro100. - 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/
Lost O_NONBLOCK (Bug?)
Hi,
I've run into the following weird behavior on my system with 2.4.0. I have
the following code:
if (fork() == 0)
{
int Flags,dummy;
if ((Flags = fcntl(STDIN_FILENO,F_GETFL,dummy)) < 0)
_exit(100);
if (fcntl(STDIN_FILENO,F_SETFL,Flags | O_NONBLOCK) < 0)
_exit(100);
while (read(STDIN_FILENO,,1) == 1);
if (fcntl(STDIN_FILENO,F_SETFL,Flags & (~(long)O_NONBLOCK)) < 0)
_exit(100);
// exec something
}
Which works fine, unless the parent process was backgrounded by the shell
(^Z then bg). If that is the case then the O_NONBLOCK seems to be lost. I
straced this:
fcntl(0, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(0, F_SETFL, O_RDWR|O_NONBLOCK)= 0
read(0, 0xbfffea38, 1) = ? ERESTARTSYS (To be restarted)
--- SIGTTIN (Stopped (tty input)) ---
--- SIGTTIN (Stopped (tty input)) ---
read(0, 0xbfffea38, 1) = ? ERESTARTSYS (To be restarted)
--- SIGTTIN (Stopped (tty input)) ---
--- SIGTTIN (Stopped (tty input)) ---
[.. etc, again and again in a tight loop ..]
--- SIGTTIN (Stopped (tty input)) ---
--- SIGTTIN (Stopped (tty input)) ---
read(0,
The last read was after the process was forgrounded. The read waits
forever, the non-block flag seems to have gone missing. It is also a
little odd I think that it repeated to get SIGTTIN which was never
actually delivered to the program.. Shouldn't SIGTTIN suspend the process?
The signal mask from /proc/xx/status (the child) looks like:
SigPnd:
SigBlk:
SigIgn: 8000
SigCgt:
Is this the expected behavior of the kernel?
Thanks,
Jason
Please CC me, I'm not on l-k today.
-
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/
auth 94b3a694 subscribe linux-kernel \
__ === - 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: UDMA(66) drive coming up as UDMA(33)?
Well, I'm positive what I have is an 80pin cable. I may try a diffrent one. I guess I could benchmark the drive in windows and see how it compares to linux. (Both are on the same drive). The HPT366 chip is integrated on the BE6 motherboard. The manual says PIO 4 mode should get about 16.6 Mb/s, UDMA 2 33 Mb/s, and UDMA 4 66 Mb/s. Does anyone know what the correct numbers I should be seeing in linux? (/w hdparm -t) Again, my hardware is: Quantum Fireball KA 13.6 7200 rpm HD Abit BE6 /w integrated HPT366 chip Kernel 2.4.3 Thanks, David St.Clair On 09 Apr 2001 19:39:23 -0700, Nicholas Knight wrote: > - Original Message - > From: "David St.Clair" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, April 07, 2001 10:36 AM > Subject: UDMA(66) drive coming up as UDMA(33)? > > > > I'm trying to get my hard drive to use UDMA/66. I'm thinking the cable > > is not being detected. When the HPT366 bios is set to UDMA 4; using > > hdparm -t, I get a transfer rate of 19.51 MB/s. When the HPT366 bios is > > set to PIO 4 the transfer rate is the same. Is this normal for a UDMA/66 > > drive? What makes me think something is wrong is that the log says > > The speed is dependant on the drive, and has absilutely nothing to do with > the UDMA mode, beyond that the controller and cable need to be able to > support at least the speed the drive is recieving/outputting data in order > for the drive to operate at full speed, 19.51MB/sec sounds right for a good > 7200RPM HDD > > > > > "ide2: BM-DMA at 0xbc00-0xbc07, BIOS settings: hde:pio" <-- PIO? > > hmm this is a little odd but I don't know the ins and outs of the HPT366 > controller > > > > > and > > > > "hde: 27067824 sectors (13859 MB) w/371KiB Cache, CHS=26853/16/63, > > UDMA(33)" <--- UDMA(33)? shouldn't it be UDMA(66)? > > > > this certainly sounds like it's not detecting the cable properly... have you > tried replacing it with a new cable that you KNOW supports ATA/66? > > > > HPT366: onboard version of chipset, pin1=1 pin2=2 > > is the HPT366 controller in an add-in card or built into the motherboard? it > looks like it's builtin from this line > > the bottom line here is that the cable probably isn't being detected > properly for some reason, I doubt if it's a kernel problem, the cable is > probably "bad", try picking up a new ATA/66+ cable and putting it in there > this shouldn't actually cause you problems unless you're often transferring > more than 33MB/sec though, which isn't likely on a desktop system, ATA/66 > and ATA/100 are *generaly* overkill for most desktop systems, even for many > powerusers - 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: [QUESTION] 2.4.x nice level
SodaPop wrote: > > I too have noticed that nicing processes does not work nearly as > effectively as I'd like it to. I run on an underpowered machine, > and have had to stop running things such as seti because it steals too > much cpu time, even when maximally niced. > > As an example, I can run mpg123 and a kernel build concurrently without > trouble; but if I add a single maximally niced seti process, mpg123 runs > out of gas and will start to skip while decoding. > > Is there any way we can make nice levels stronger than they currently are > in 2.4? Or is this perhaps a timeslice problem, where once seti gets cpu > time it runs longer than it should since it makes relatively few system > calls? > In kernel/sched.c for HZ < 200 an adjustment of nice to tick is set up to be nice>>2 (i.e. nice /4). This gives the ratio of nice to time slice. Adjustments are made to make the MOST nice yield 1 jiffy, so using this scale and remembering nice ranges from -19 to 20 the least nice is 40/4 or 10 ticks. This implies that if only two tasks are running and they are most and least niced then one will get 1/11 of the processor, the other 10/11 (about 10% and 90%). If one is niced and the other is not you get 1 and 5 for the time slices or 1/6 and 5/6 (17% and 83%). In 2.2.x systems the full range of nice was used one to one to give 1 and 39 or 40 or 2.5% and 97.5% for max nice to min. For most nice to normal you would get 1 and 20 or 4.7% and 95.3%. The comments say the objective is to come up with a time slice of 50ms, presumably for the normal nice value of zero. After translating the range this would be a value of 20 and, yep 20/4 give 5 jiffies or 50 ms. Sure puts a crimp in the min to max range, however. George - 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/
Swap Corruption in 2.4.3 ?
Hi all, When I unmount the swapfile I get: VM: Undead swap entry 000bb300 VM: Undead swap entry 00abb300 VM: Undead swap entry 016fb300 I can repeat this fairly reliably. First fill up the conventional memory, and a few 10s of Mb of swap, then put the machine under a bit of a load. It may not be the loading that's causing this, just the movement in swap. First things stop working, e.g. shared libraries appear to be missing or corrupt, every program segfaults on startup, occasionally the whole machines hangs. I have seen Oopses but if memory is being corrupted I doubt they'll be any use. If I reboot, everything is fine again. The machine is a 800Mhz PIII, all IDE, all ext2, not overclocked, with a vanilla 2.4.3 kernel (compiled with gcc-2.91.66). I can reproduce this with DMA turned off. I cannot reproduce this with the swap file off, however hard I try. If the swapfile isn't touched the machine seems stable under load. Below is my .config (if it's useful) Can anyone think of anything else I can test to give you any pointers? Cheers, FlatCap (Richard Russon) [EMAIL PROTECTED] CONFIG_X86=y CONFIG_ISA=y CONFIG_UID16=y CONFIG_EXPERIMENTAL=y CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y CONFIG_MPENTIUMIII=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_NOHIGHMEM=y CONFIG_MTRR=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_NET=y CONFIG_PCI=y CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y CONFIG_SYSVIPC=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y CONFIG_BINFMT_ELF=y CONFIG_PARPORT=y CONFIG_PARPORT_PC=y CONFIG_PNP=y CONFIG_ISAPNP=y CONFIG_BLK_DEV_FD=y CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_PACKET=y CONFIG_NETLINK=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_BLK_DEV_CMD640=y CONFIG_BLK_DEV_RZ1000=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_IDEDMA=y CONFIG_IDEDMA_AUTO=y CONFIG_BLK_DEV_IDE_MODES=y CONFIG_SD_EXTRA_DEVS=40 CONFIG_SR_EXTRA_DEVS=2 CONFIG_SCSI_DEBUG_QUEUES=y CONFIG_SCSI_MULTI_LUN=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 CONFIG_MOUSE=y CONFIG_PSMOUSE=y CONFIG_AGP_SIS=y CONFIG_AUTOFS4_FS=y CONFIG_JOLIET=y CONFIG_PROC_FS=y CONFIG_DEVPTS_FS=y CONFIG_EXT2_FS=y CONFIG_NFS_V3=y CONFIG_NFSD_V3=y CONFIG_LOCKD_V4=y CONFIG_SMB_NLS_DEFAULT=y CONFIG_SMB_NLS_REMOTE="cp437" CONFIG_MSDOS_PARTITION=y CONFIG_SMB_NLS=y CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_CODEPAGE_850=y CONFIG_NLS_ISO8859_1=y CONFIG_NLS_ISO8859_15=y CONFIG_VGA_CONSOLE=y CONFIG_VIDEO_SELECT=y CONFIG_SOUND=y CONFIG_BLK_DEV_IDECD=m CONFIG_8139TOO=m CONFIG_NE2K_PCI=m CONFIG_BLK_DEV_IDECD=m CONFIG_FAT_FS=m CONFIG_VFAT_FS=m CONFIG_SOUND_ES1371=m - 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/
Asus CUR-DLS SMP motherboard
Hello, I'm wondering if anyone has used this motherboard and can confirm if it works under 2.4.3 or not. Having been burned by the Via-based CUV4X-D not working under Linux, I'm keen to find out if this ServerWorks-based board works or not, before throwing away my money. Asus CUR-DLS, ATX, ServerWorks ServerSet III LE, FC-PGA,LAN/SCSI/VGA Specifications: CPU: FCPGA PIII 500-866+MHz/SMP (Symmetical Multi-Processor) dual processors, Socket 370, Chipset: ServerWorks (RCC) ServerSet III LE, Slots: 2 x PCI-64bit/66MHz, 5 x PCI-32bit/33MHz , 1 x ASMS socket (reserved for IPMI/EMP), 4x DIMM. Formfactor: ATX, 66/100/133MHz FSB, DMA-33, PC133 memory support (supports Registered DIMM only, ECC based 64MB to 1GB memory capacity). Built in Intel 82559 LAN, LSI dual channel Ultra160 SCSI controller, ATI Rage-XL graphics with 4MB PC100 SDRAM Any anecdotes? Alternatively, is anyone working on a patch for the Via 694XDP problems? Thanks in advance, Simon Garner - 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/scsi
You write: > are there samples of linux codes that can talk to SCSI harddisk, scanners > and > cameras in the Linux kernel. Like in windows NT, one does not need to write > driver for his scsi device. Just use some scsi interface libraries to talk > to the scsi device. Is there such examples in linux?.I need to learn this so > that i can develop the same thing for a scsi digital camera. See the SANE project, which has support for lots of SCSI scanners, and is the defacto standard for image acquisition for GIMP and such. It has lots of other good features already (dynamic loading of backends (i.e. "device drivers"), network device access, GUI/text front ends, etc). I believe it is also being used for other high-end image acquisition devices, not just scanners. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - 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/
AIC7XXX oddities
Greetings, I've been using the new aic7xxx driver, and updating frequently from Justin's site. I'm at v6.1.11 now with kernel 2.4.3 and still experiencing some odd behaviour. For example, I start as such on BUS 0 (an aic-29160): Channel A Target 5 Negotiation Settings User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit) Goal: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit) Curr: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit) Channel A Target 5 Lun 0 Settings Commands Queued 13199 Commands Active 0 Command Openings 49 Max Tagged Openings 253 Device Queue Frozen Count 0 After an invocation of cdrecord --scanbus dmesg reveals this on BUS1 (an aha-2940u2w): (scsi1:A:1): 5.000MB/s transfers (5.000MHz, offset 15) (scsi1:A:6): 20.000MB/s transfers (20.000MHz, offset 15) (locating burner at 6, and zip at 5) An invocation of hdparm -Tt /dev/sda (id 5) does this: (scsi1:A:1): 5.000MB/s transfers (5.000MHz, offset 15) (scsi1:A:6): 20.000MB/s transfers (20.000MHz, offset 15) (scsi0:A:5): 3.300MB/s transfers cat /proc/scsi/aic7xxx/0 : Channel A Target 5 Negotiation Settings User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit) Goal: 3.300MB/s transfers Curr: 3.300MB/s transfers Channel A Target 5 Lun 0 Settings Commands Queued 16817 Commands Active 0 Command Openings 49 Max Tagged Openings 253 Device Queue Frozen Count 0 Target 5 has dropped to 3.300MB/s ?? thanks, Ethan W. --- Get free personalized email at http://www.iname.com - 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: rw_semaphores
Hello, At Sun, 8 Apr 2001 20:08:13 -0700 (PDT), Linus Torvalds wrote: > > Can anybody shoot any holes in this? I haven't actually tested it, but > race conditions in locking primitives are slippery things, and I'd much > rather have an algorithm we can _think_ about and prove to be working. And > I think the above one is provably correct. I am not familiar with semaphore or x86, so this may not be correct, but if the following sequence is possible, the writer can call wake_up() before the reader calls add_wait_queue() and reader may sleep forever. Is it possible? Reader Writer down_read: lock incl (%sem) js __down_read_failed up_write: lock andl $0x3fff,(%sem) jne __up_write_wakeup __up_write_wakeup: spin_lock(>lock); wake_up(>waiters); spin_unlock(>lock); __down_read_failed: spin_lock(%sem->lock) add_wait_queue(>waiters, ); . . - 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: Increasing the FD_SETSIZE
> I am having trouble with increasing the file descriptor size for my > application - it opens several files for each client session (and needs > to keep them open as long as the session is active, which can be upto 3 > hours long). What I see from the application is "open failed in > FileStreamReader::setupFile: Too many open files". > > I have bumped up /proc/sys/fs/file-max to 16K, but I am failing at 2638 > (cat /proc/sys/fs/file-max returns "2638 97 16384") when the number of > files my app opened reached 1023. > > There is a comment in /usr/include/linux/posix_types.h regarding > __FD_SETSIZE being set to 1024. How can I increase this value? You are tinkering with the wrong value. FD_SETSIZE affects fd_sets used in the 'select' system call. If you don't use select (and you shouldn't) it's not an issue. Also, tampering with the system-wide limits is the wrong approach too. There is no problem in the kernel for you to fix. What you are hitting is a per-process resource limit. Read the man pages on 'setrlimit' or the bash help on 'ulimit'. DS - 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: UDMA(66) drive coming up as UDMA(33)?
- Original Message - From: "David St.Clair" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, April 07, 2001 10:36 AM Subject: UDMA(66) drive coming up as UDMA(33)? > I'm trying to get my hard drive to use UDMA/66. I'm thinking the cable > is not being detected. When the HPT366 bios is set to UDMA 4; using > hdparm -t, I get a transfer rate of 19.51 MB/s. When the HPT366 bios is > set to PIO 4 the transfer rate is the same. Is this normal for a UDMA/66 > drive? What makes me think something is wrong is that the log says The speed is dependant on the drive, and has absilutely nothing to do with the UDMA mode, beyond that the controller and cable need to be able to support at least the speed the drive is recieving/outputting data in order for the drive to operate at full speed, 19.51MB/sec sounds right for a good 7200RPM HDD > > "ide2: BM-DMA at 0xbc00-0xbc07, BIOS settings: hde:pio" <-- PIO? hmm this is a little odd but I don't know the ins and outs of the HPT366 controller > > and > > "hde: 27067824 sectors (13859 MB) w/371KiB Cache, CHS=26853/16/63, > UDMA(33)" <--- UDMA(33)? shouldn't it be UDMA(66)? > this certainly sounds like it's not detecting the cable properly... have you tried replacing it with a new cable that you KNOW supports ATA/66? > HPT366: onboard version of chipset, pin1=1 pin2=2 is the HPT366 controller in an add-in card or built into the motherboard? it looks like it's builtin from this line the bottom line here is that the cable probably isn't being detected properly for some reason, I doubt if it's a kernel problem, the cable is probably "bad", try picking up a new ATA/66+ cable and putting it in there this shouldn't actually cause you problems unless you're often transferring more than 33MB/sec though, which isn't likely on a desktop system, ATA/66 and ATA/100 are *generaly* overkill for most desktop systems, even for many powerusers - 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: Version 6.1.11 of the aic7xxx driver availalbe
>So, what about on an alpha system. I've asked a few times what I could do, >but you didn't help nor explain what you meant. >From talking to the maintainer of the QLogic driver, it appears that there is a generic issue with data mapping on the Alpha. The only way to correct this issue will be for someone to debug it. -- Justin - 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: UDMA(66) drive coming up as UDMA(33)?
- Original Message - From: "Wilfried Weissmann" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, April 08, 2001 10:44 AM Subject: Re: UDMA(66) drive coming up as UDMA(33)? > "David St.Clair" wrote: > > > > I'm trying to get my hard drive to use UDMA/66. I'm thinking the cable > > is not being detected. When the HPT366 bios is set to UDMA 4; using > > I think that should be UDMA 5 for 66? As far as I can remember UDMA4 is 33MHz with S.M.A.R.T. which > add some reporting functionality. But I might be wrong... 66 is 4, 100 is 5, - 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: Version 6.1.11 of the aic7xxx driver availalbe
> As always, the latest version of this driver is availalbe here: > > http://people.FreeBSD.org/~gibbs/linux/ > > This site now includes installation instructions, feature set, > etc. The page is under construction - comments welcome. > > For the impatient: > > CHANGELOG: > http://people.FreeBSD.org/~gibbs/linux/CHANGELOG > > 2.4.3-patch: > http://people.FreeBSD.org/~gibbs/linux/linux-aic7xxx-6.1.11-2.4.3.patch.gz > > 2.2.19-patch: > http://people.FreeBSD.org/~gibbs/linux/linux-aic7xxx-6.1.11-2.2.19.patch.gz So, what about on an alpha system. I've asked a few times what I could do, but you didn't help nor explain what you meant. -- Lab tests show that use of micro$oft causes cancer in lab animals - 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/
Increasing the FD_SETSIZE
Hi, I am having trouble with increasing the file descriptor size for my application - it opens several files for each client session (and needs to keep them open as long as the session is active, which can be upto 3 hours long). What I see from the application is "open failed in FileStreamReader::setupFile: Too many open files". I have bumped up /proc/sys/fs/file-max to 16K, but I am failing at 2638 (cat /proc/sys/fs/file-max returns "2638 97 16384") when the number of files my app opened reached 1023. There is a comment in /usr/include/linux/posix_types.h regarding __FD_SETSIZE being set to 1024. How can I increase this value? Thanks, Ram Madduluri begin:vcard n:Madduluri;Ram x-mozilla-html:FALSE url:http://www.kasenna.com org:Kasenna Inc adr:;; version:2.1 email;internet:[EMAIL PROTECTED] x-mozilla-cpt:;864 fn:Ram Madduluri end:vcard
linux/scsi
are there samples of linux codes that can talk to SCSI harddisk, scanners and cameras in the Linux kernel. Like in windows NT, one does not need to write driver for his scsi device. Just use some scsi interface libraries to talk to the scsi device. Is there such examples in linux?.I need to learn this so that i can develop the same thing for a scsi digital camera. J _ Get your FREE download of MSN Explorer at http://explorer.msn.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4-pre1 Unresolved symbols "strstr"
got this path from Niels ... Works for me now. ___ > From: Niels Kristian Bech Jensen <[EMAIL PROTECTED]> Try this patch: diff -u --recursive --new-file v2.4.4-pre1/linux/arch/i386/kernel/i386_ksyms.c linux/arch/i386/kernel/i386_ksyms.c --- v2.4.4-pre1/linux/arch/i386/kernel/i386_ksyms.c Sun Apr 8 17:57:45 2001+++ linux/arch/i386/kernel/i386_ksyms.c Mon Apr 9 08:00:13 2001 @@ -97,6 +97,7 @@ EXPORT_SYMBOL_NOVERS(__put_user_2); EXPORT_SYMBOL_NOVERS(__put_user_4); +EXPORT_SYMBOL(strstr); EXPORT_SYMBOL(strtok); EXPORT_SYMBOL(strpbrk); EXPORT_SYMBOL(simple_strtol); -- ___ Thanks, Jeff [ [EMAIL PROTECTED] ] On Tue, 10 Apr 2001, Nick Urbanik wrote: > Jeff Chua wrote: > > > depmod version 2.4.5 > > > > Compiled 2.4.4-pre1 but running "depmod" generates a lot of these ... > > > > depmod: *** Unresolved symbols in > > /lib/modules/2.4.4-pre1/kernel/drivers/char/ltmodem.o > > depmod: strstr > > depmod: *** Unresolved symbols in > > /lib/modules/2.4.4-pre1/kernel/drivers/char/serial.o > > depmod: strstr > > depmod: *** Unresolved symbols in > > /lib/modules/2.4.4-pre1/kernel/drivers/ide/ide-cd.o > > depmod: strstr > > depmod: *** Unresolved symbols in > > /lib/modules/2.4.4-pre1/kernel/drivers/ide/ide-mod.o > > depmod: strstr > > depmod: *** Unresolved symbols in > > /lib/modules/2.4.4-pre1/kernel/drivers/ide/ide-probe-mod.o > > depmod: strstr > > depmod: *** Unresolved symbols in > > /lib/modules/2.4.4-pre1/pcmcia/xirc2ps_cs.o > > depmod: strstr > > depmod: *** Unresolved symbols in /lib/modules/2.4.4-pre1/kernel/drivers/ide/ide-cd.o > depmod: strstr > depmod: *** Unresolved symbols in >/lib/modules/2.4.4-pre1/kernel/drivers/ide/ide-tape.o > depmod: strstr > depmod: *** Unresolved symbols in >/lib/modules/2.4.4-pre1/kernel/drivers/isdn/avmb1/capidrv.o > depmod: strstr > depmod: *** Unresolved symbols in >/lib/modules/2.4.4-pre1/kernel/drivers/isdn/icn/icn.o > depmod: strstr > depmod: *** Unresolved symbols in /lib/modules/2.4.4-pre1/kernel/drivers/net/de4x5.o > depmod: strstr > depmod: *** Unresolved symbols in /lib/modules/2.4.4-pre1/kernel/drivers/net/depca.o > depmod: strstr > depmod: *** Unresolved symbols in /lib/modules/2.4.4-pre1/kernel/drivers/net/ewrk3.o > depmod: strstr > depmod: *** Unresolved symbols in >/lib/modules/2.4.4-pre1/kernel/drivers/net/hamradio/baycom_epp.o > depmod: strstr > depmod: *** Unresolved symbols in >/lib/modules/2.4.4-pre1/kernel/drivers/parport/parport.o > depmod: strstr > > This is on a Cyrix P-166. Same with depmod 2.4.2 or 2.3.21 > > -- > Nick Urbanik, Dept. of Computing and Mathematics > Hong Kong Institute of Vocational Education (Tsing Yi) > email: [EMAIL PROTECTED] > Tel: (852) 2436 8576, (852) 2436 8579 Fax: (852) 2435 1406 > pgp ID: 7529555D fingerprint: 53 B6 6D 73 52 EE 1F EE EC F8 21 98 45 1C 23 7B > > > > - > 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/ > - 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: goodbye
On Mon, 9 Apr 2001, Joseph Carter wrote: > On Tue, Apr 10, 2001 at 01:00:08AM +0300, Matti Aarnio wrote: > > Dave said "remove DUL", I did that. > > > > VGER uses now RBL and RSS, no others. > > Thank you, I don't believe there is anyone on this list who is likely > to object to these lists. It might even be good to add inputs.orbs.org to vger. This list is basically the same as RSS, except that sites can get on and off faster (RSS is sometimes slow in adding sites to the list and it is at times also slow in removing sites that have already been fixed). regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - 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: Serial port latency
On Sun, Mar 25, 2001 at 11:10:14PM +, Pavel Machek wrote: > I've seen similar bugs. If you hook something on schedule_tq and forget > to set current->need_resched, this is exactly what you get. keventd fixes tq_scheduler case (tq_scheduler is dead). Andrea - 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/
ide.2.2.19.04092001.patch
This is up with some updates Short notice development for Promise Ultra100 TX2 sponsored by Penguin Computer and again little/no help from Promise. This is a unique chipset that does setfeatures sensing of the transfer rates and thus it is counter to the standard Promise design. It does still use the pdc202xx.c chipset code, but much of it is skipped over to preserve the hidden settings calls. The one issue for this chipset is that it may not be ideal for hotswap as the unknown states are issues. DiskPerf /dev/hde Device: IBM-DTLA-307075 Serial Number: YSDYSFA5874 LBA 0 DMA Read Test = 63.35 MB/Sec (3.95 Seconds) Outer Diameter Sequential DMA Read Test = 35.89 MB/Sec (6.97 Seconds) Inner Diameter Sequential DMA Read Test = 17.64 MB/Sec (14.17 Seconds) CR3's adjusted: for kernel transfer rates and conservative LBA 0 DMA Read Test = 85.52 MB/Sec Outer Diameter Sequential DMA Read Test = 48.45 MB/Sec Inner Diameter Sequential DMA Read Test = 23.81 MB/Sec There is about a 35%-40% under reporting of performance from kernel to user-space ioctl calls. Cheers, Andre Hedrick Linux ATA Development - 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: Compaq proliant ML-350 - IDE & SCSI
2.4.4-p1 is the kernel version that i've tried now. no succes with 2.4.3 and below. i've been trying without the CDROM and a normal HDD ata 66. i've made some progress using the normal ide ata 66 driver and removing the osv4 from kernel. root@light:/# hdparm -t -T /dev/hda /dev/hda: Timing buffer-cache reads: 128 MB in 0.81 seconds =158.02 MB/sec Timing buffered disk reads: MB in 8.41 seconds = 7.61 MB/sec root@light:/# hdparm -v /dev/hda /dev/hda: multcount= 16 (on) I/O support = 0 (default 16-bit) unmaskirq= 0 (off) using_dma= 1 (on) keepsettings = 0 (off) nowerr = 0 (off) readonly = 0 (off) readahead= 8 (on) geometry = 2586/240/63, sectors = 39102336, start = 0 still my bios is set to enhaced DMA. i am still working on UDMA. if u have any suggestions i still wait for a solution. axl - Original Message - From: "Mark Hahn" <[EMAIL PROTECTED]> To: "Alexandru Barloiu Nicolae" <[EMAIL PROTECTED]> Sent: Tuesday, April 10, 2001 1:39 AM Subject: Re: Compaq proliant ML-350 - IDE & SCSI > > ServerWorks OSB4: IDE controller on PCI bus 00 dev 79 > > ugh. not a widely-respected implementation. I don't think you mentioned > which kernel you're runnint, either, since there have been several successive > generations of workarounds for SW ide/etc stuff. > > > hda: WDC WD200EB-00BHF0, ATA DISK drive > > hdb: Compaq CRD-8402B, ATAPI CD/DVD-ROM drive > > sharing a channel like this is not a good idea. you should definitely > test without the cdrom drive. all your ide cables are 18" or less? > - 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] Process pinning
This patch applies cleanly to 2.4.3-ac3.
Changes to array.c expose cpus_allowed in proc/pid/stat.
PR_GET_RUNON and PR_SET_RUNON were done by Ingo and Dimitris. Added
MUSTRUN_PID and RUNANY_PID.
Also attached is runon and it's manpage.
Nick
diff -X /home/npollitt/dontdiff -Nur 243-ac3/linux/fs/proc/array.c
mine/linux/fs/proc/array.c
--- 243-ac3/linux/fs/proc/array.c Tue Mar 27 16:21:37 2001
+++ mine/linux/fs/proc/array.c Tue Mar 27 16:23:24 2001
@@ -343,7 +343,7 @@
read_unlock(_lock);
res = sprintf(buffer,"%d (%s) %c %d %d %d %d %d %lu %lu \
%lu %lu %lu %lu %lu %ld %ld %ld %ld %ld %ld %lu %lu %ld %lu %lu %lu %lu %lu \
-%lu %lu %lu %lu %lu %lu %lu %lu %d %d\n",
+%lu %lu %lu %lu %lu %lu %lu %lu %d %d %lu\n",
task->pid,
task->comm,
state,
@@ -386,7 +386,8 @@
task->nswap,
task->cnswap,
task->exit_signal,
- task->processor);
+ task->processor,
+ task->cpus_allowed);
if(mm)
mmput(mm);
return res;
diff -X /home/npollitt/dontdiff -Nur 243-ac3/linux/include/linux/prctl.h
mine/linux/include/linux/prctl.h
--- 243-ac3/linux/include/linux/prctl.h Sun Mar 19 11:15:32 2000
+++ mine/linux/include/linux/prctl.hTue Mar 27 16:23:24 2001
@@ -20,4 +20,9 @@
#define PR_GET_KEEPCAPS 7
#define PR_SET_KEEPCAPS 8
+#define PR_GET_RUNON 9
+#define PR_SET_RUNON 10
+#define PR_MUSTRUN_PID11
+#define PR_RUNANY_PID 12
+
#endif /* _LINUX_PRCTL_H */
diff -X /home/npollitt/dontdiff -Nur 243-ac3/linux/kernel/sched.c
mine/linux/kernel/sched.c
--- 243-ac3/linux/kernel/sched.cTue Mar 27 16:21:38 2001
+++ mine/linux/kernel/sched.c Tue Mar 27 16:23:24 2001
@@ -112,6 +112,10 @@
#ifdef CONFIG_SMP
#define idle_task(cpu) (init_tasks[cpu_number_map(cpu)])
+#define can_schedule_goodness(p,cpu) ( (!(p)->has_cpu || \
+p->processor == cpu) && \
+((p)->cpus_allowed & (1 << cpu)))
+
#define can_schedule(p,cpu) ((!(p)->has_cpu) && \
((p)->cpus_allowed & (1 << cpu)))
@@ -119,6 +123,7 @@
#define idle_task(cpu) (_task)
#define can_schedule(p,cpu) (1)
+#define can_schedule_goodness(p,cpu) (1)
#endif
@@ -594,7 +599,7 @@
still_running_back:
list_for_each(tmp, _head) {
p = list_entry(tmp, struct task_struct, run_list);
- if (can_schedule(p, this_cpu)) {
+ if (can_schedule_goodness(p, this_cpu)) {
int weight = goodness(p, this_cpu, prev->active_mm);
if (weight > c)
c = weight, next = p;
diff -X /home/npollitt/dontdiff -Nur 243-ac3/linux/kernel/sys.c mine/linux/kernel/sys.c
--- 243-ac3/linux/kernel/sys.c Tue Mar 27 16:21:38 2001
+++ mine/linux/kernel/sys.c Tue Mar 27 16:23:24 2001
@@ -1255,12 +1255,95 @@
}
current->keep_capabilities = arg2;
break;
+ case PR_GET_RUNON:
+ error = put_user(current->cpus_allowed, (long *)arg2);
+ break;
+ case PR_SET_RUNON:
+ if (arg2 == 0)
+ arg2 = 1 << smp_processor_id();
+ arg2 &= cpu_online_map;
+ if (!arg2)
+ error = -EINVAL;
+ else {
+ current->cpus_allowed = arg2;
+ if (!(arg2 & (1 << smp_processor_id(
+ current->need_resched = 1;
+ }
+ break;
+ case PR_MUSTRUN_PID:
+ /* arg2 is cpu, arg3 is pid */
+ if (arg2 == 0)
+ arg2 = 1 << smp_processor_id();
+ arg2 &= cpu_online_map;
+ if (!arg2)
+ error = -EINVAL;
+ error = mp_mustrun_pid(arg2, arg3);
+ break;
+ case PR_RUNANY_PID:
+ /* arg2 is pid */
+ if (!arg2)
+ error = -EINVAL;
+ error = mp_runany_pid(arg2);
+ break;
default:
error = -EINVAL;
break;
}
return error;
}
+
+static int mp_mustrun_pid(int cpu, int pid)
+{
+ struct task_struct *p;
+ int ret;
+
+ ret = -EPERM;
+ /* Not allowed to change 1 */
+ if (pid == 1)
+ goto out;
+
+ read_lock(_lock);
+ p = find_task_by_pid(pid);
+ if (p)
+ get_task_struct(p);
+ read_unlock(_lock);
+ if (!p)
+
Re: vmlinuz won't build with cmd64X.C
Sorry, figured it out. Jordan Jordan wrote: > > I went in to my .config and disabled 640 and 640 enhanced in favor of > trying the 64x ide support. I especially liked the fact that from the > code it look to have a /proc table similar the the via driver for my > onboard controller. Then during compile I can not get the 64x to > correctly build itself into the kernel. Actually it build into the > kernel but during the final steps the whole build fails becuase of these > errors: > > make[2]: Leaving directory `/usr/src/linux/arch/i386/lib' > make[1]: Leaving directory `/usr/src/linux/arch/i386/lib' > ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext > arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o > init/version.o \ > --start-group \ > arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o > mm/mm.o fs/fs.o ipc/ipc.o \ > drivers/block/block.o drivers/char/char.o drivers/misc/misc.o > drivers/net/net.o drivers/media/media.o drivers/parport/driver.o > drivers/char/agp/agp.o drivers/char/drm/drm.o drivers/ide/idedriver.o > drivers/scsi/scsidrv.o drivers/cdrom/driver.o > drivers/sound/sounddrivers.o drivers/pci/driver.o drivers/pnp/pnp.o > drivers/video/video.o drivers/usb/usbdrv.o drivers/input/inputdrv.o > drivers/acpi/acpi.o \ > net/network.o \ > /usr/src/linux/arch/i386/lib/lib.a /usr/src/linux/lib/lib.a > /usr/src/linux/arch/i386/lib/lib.a \ > --end-group \ > -o vmlinux > drivers/ide/idedriver.o: In function `ide_setup': > drivers/ide/idedriver.o(.text.init+0x712): undefined reference to > `cmd640_vlb' > drivers/ide/idedriver.o: In function `probe_for_hwifs': > drivers/ide/idedriver.o(.text.init+0x918): undefined reference to > `ide_probe_for_cmd640x' > drivers/ide/idedriver.o: In function `pci_init_cmd64x': > drivers/ide/idedriver.o(.text.init+0xb2a): undefined reference to > `cmd64x_display_info' > make: *** [vmlinux] Error 1 > > I am running 2.4.3-ac3. Thanks for any help, I would really like to be > able to try 64x as opposed to 640. > > Jordan > - > 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/ - 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: goodbye
On Tue, Apr 10, 2001 at 01:00:08AM +0300, Matti Aarnio wrote: > Dave said "remove DUL", I did that. > > VGER uses now RBL and RSS, no others. Thank you, I don't believe there is anyone on this list who is likely to object to these lists. -- Joseph Carter <[EMAIL PROTECTED]>Free software developer C'mon! political protest! sheesh. Where's that anarchist spirit? ;-) -- Decklin Foster PGP signature
Re: aic7xxx and 2.4.3 failures
On 04.10 Vivek Dasmohapatra wrote: > On Mon, 9 Apr 2001, Alan Cox wrote: > > > > A typical startup with 6.1.9 proceeds like this... (6.1.10 hangs silently > > > after emitting the scsi0 and scsi1 adapter summaries, maybe it is > > > going through the same gyrations silently.) > > > > Try saying N to the AIC7xxx driver and Y to AIC7XXX_OLD and see if that > works. > > I had similar problems w. 2.4.3 on an SMP aic7xx PII, box: new driver > never managed to mount the root partition - always panicked first. Old > driver worked fine. > I am using 2.4.3-ac3 successfully with 6.1.8, 9 and 10, and now building with 11. -- J.A. Magallon # Let the source mailto:[EMAIL PROTECTED] # be with you, Luke... Linux werewolf 2.4.3-ac3 #1 SMP Thu Apr 5 00:28:45 CEST 2001 i686 - 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: [Lse-tech] Re: [PATCH for 2.5] preemptible kernel
On Mon, 9 Apr 2001 [EMAIL PROTECTED] wrote: > As you've observed, with the approach of waiting for all pre-empted tasks > to synchronize, the possibility of a task staying pre-empted for a long > time could affect the latency of an update/synchonize (though its hard for > me to judge how likely that is). It's very unlikely on a system that doesn't already have problems with CPU starvation because of runaway real-time tasks or interrupt handlers. First, preemption is a comparitively rare event with a mostly timesharing load, typically from 1% to 10% of all context switches. Second, the scheduler should not penalize the preempted task for being preempted, so that it should usually get to continue running as soon as the preempting task is descheduled, which is at most one timeslice for timesharing tasks. Nigel Gamble[EMAIL PROTECTED] Mountain View, CA, USA. http://www.nrg.org/ MontaVista Software [EMAIL PROTECTED] - 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: PROBLEM: make oldconfig can change Alpha system type on 2.2.19
>From kufel!ankry Tue Apr 10 01:04:13 2001 Return-Path: Received: from kufel.UUCP (uucp@localhost) by green.mif.pg.gda.pl (8.9.3/8.9.3) with UUCP id BAA01672 for green.mif.pg.gda.pl!ankry; Tue, 10 Apr 2001 01:04:13 +0200 Received: (from ankry@localhost) by kufel.dom (8.9.3/8.9.3) id BAA03695 for [EMAIL PROTECTED]; Tue, 10 Apr 2001 01:04:06 +0200 From: Andrzej Krzysztofowicz Message-Id: <[EMAIL PROTECTED]> Subject: Re: PROBLEM: make oldconfig can change Alpha system type on 2.2.19 To: kufel!green.mif.pg.gda.pl!ankry Date: Tue, 10 Apr 2001 01:04:06 +0200 (CEST) In-Reply-To: <[EMAIL PROTECTED]> from "Andrzej Krzysztofowicz" at kwi 05, 2001 03:00:40 X-Mailer: ELM [version 2.5 PL0pre8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Brian Campbell wrote:" > To: [EMAIL PROTECTED] > From: Brian Campbell <[EMAIL PROTECTED]> > [1.] One line summary of the problem: > make oldconfig can change Alpha system type on 2.2.19 > > [2.] Full description of the problem/report: > With the system type set to `Cabriolet' (CONFIG_ALPHA_CABRIOLET) > running make oldconfig causes it to change to `EB64+' (CONFIG_ALPHA_EB64P) > without asking. As I see the same problem appears also with the following Alpha architecture settings: Alpha-XL (-> Avanti) AlphaBook1 (-> Noname) As it is quite easy to avoid this mis-setting in Configure (make config/oldconfig) by the following hack: if [ "$CONFIG_ALPHA_CABRIOLET" = "y" ]; then unset CONFIG_ALPHA_EB64P fi if [ "$CONFIG_ALPHA_XL" = "y" ]; then unset CONFIG_ALPHA_AVANTI fi if [ "$CONFIG_ALPHA_BOOK1" = "y" ]; then unset CONFIG_ALPHA_NONAME fi choice 'Alpha system type' ... it can't help with xconfig. And (IMHO) it is just a hack, not a proper solution. The proper solution is probably to move three of the above "system type" settings outside the main menu. Does anybody know differences between the mentioned above three pairs of system types and how to do it? Same problem appears in the 2.4 series. Andrzej -- === Andrzej M. Krzysztofowicz [EMAIL PROTECTED] tel. (0-58) 347 14 61 Wydz.Fizyki Technicznej i Matematyki Stosowanej Politechniki Gdanskiej - 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: [OT] Re: goodbye
> > >> So, Mr. Admin, setup your laptop to use SSL to your SMTP and POP >> server and authenticate with a client side certificate on your >> laptop. Welcome to the 21st century. You may, however, need a little >> more infrastructure than you can pull from your favourite distribution >> box. > > > RFC 2487STARTTLS > RFC 2554SMTP-Auth, + M$ Exchange / + Netscape > ( + a bunch of other authenticator methods ) > > Under encryption, plaintext username + password login. > The IETF protocols DO NOT support plaintext login for > obvious security reasons. > > No hazzles about autenticating by certificates. > > Availability of the feature is probably excidingly rare.. Actually TLS/SASL is exactly what I use on my systems and I offer it to whomever needs it. The way I do it is at http://blue-labs.org/clue/sendmail.html. -d - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: build -->/usr/src/linux
In article <9aqmgo$8f6ol$[EMAIL PROTECTED]> you write: >In article <[EMAIL PROTECTED]>, >Marvin Stodolsky <[EMAIL PROTECTED]> wrote: >>Thanks for responding. But I would still like to understand what the >>functionality is of the build --> /usr/src/linuc. Is it dispensable, >>once the module tree has been installed? > >It's needed for modules that are distributed sperately, so that >they can use cc -I /lib/modules/`uname -r`/build/include > >Or even > > l=`pwd` > cd /lib/modules/`uname -r`/build > make $l/module.o > >.. but there should be a cleaner way to get at the CFLAGS used >to compile the kernel. A. Not again. uname does not always provide useful information (cross compiling). Even if you're building the same ISA, you maybe in a chroot'ed environment. Can we please not assume that everybody only ever builds native... > >Mike. richard. --- Richard Offer Technical Lead, Trust Technology. "Specialization is for insects" __http://reality.sgi.com/offer/ --- Richard Offer Technical Lead, Trust Technology. "Specialization is for insects" __http://reality.sgi.com/offer/ - 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: Sound problem with 2.2.19
Originally to: Sean Rima * Sean Rima's head hit the keyboard and wrote: SR> I am sorry if this is old news but I have not seen any mention of it in the SR> list. SR> I keep getting "kernel: Sound error: Couldn't allocate DMA buffer" in my SR> syslog. However sound was working until this morning. The machine uptime is SR> below :) SR> The PC is a IBM PS/2 486DX2, with an AWE32 with 256k. The PC is fitted with SR> 16mb of ram. I have never reported a problem before so excuse if it is a bit SR> strange. Since this posting, in fact in the last 2 minutes, sound has reappeared. I haven't rebooted, changed anything and all the same processes are still running. Sean -- GNUPG ID 92B9D0CF| YAIM: thecivvie| Fidonet and BBS ICQ: 679813 | Homepage: http://www.tcob1.net | Newsportal at Linux User: #124682 | AIM: tcobone | tcob1.uklinux.net My last power cut was 3d, 6h and 48m ago on Linux 2.2.19. <-> Information This message originated from a Fidonet system and was gated at There Can Only be 1 (http://www.tcob1.net) For information of Fidonet visit http://www.fidonet.org Please do not respond direct to this message but via the - 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: No 100 HZ timer !
> > Its worth doing even on the ancient x86 boards with the PIT. > > Note that programming the PIT is slw and doing it on every timer > add_timer/del_timer would be a pain. You only have to do it occasionally. When you add a timer newer than the current one (arguably newer by at least 1/2*HZ sec) When you finish running the timers at an interval and the new interval is significantly larger than the current one. Remember each tick we poke the PIT anyway - 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: aic7xxx and 2.4.3 failures
On Mon, 9 Apr 2001, Alan Cox wrote: > > A typical startup with 6.1.9 proceeds like this... (6.1.10 hangs silently > > after emitting the scsi0 and scsi1 adapter summaries, maybe it is > > going through the same gyrations silently.) > > Try saying N to the AIC7xxx driver and Y to AIC7XXX_OLD and see if that works. I had similar problems w. 2.4.3 on an SMP aic7xx PII, box: new driver never managed to mount the root partition - always panicked first. Old driver worked fine. -- "Aren't you ashamed of yourself?" "No, I have people to do that for me." - 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: No 100 HZ timer !
> > this is one of linux biggest weaknesses. the fixed interval timer is a > > throwback. it should be replaced with a variable interval timer with interrupts > > on demand for any system with a cpu sane/modern enough to have an on-chip > > interrupting decrementer. (i.e just about any modern chip) > > Its worth doing even on the ancient x86 boards with the PIT. Note that programming the PIT is slw and doing it on every timer add_timer/del_timer would be a pain. Mikulas - 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/
No Subject
Group, Here's my last try. I've edited all of the headers (sched.h, param.h, limits.h) in /usr/include and /usr/src/linux, I've recompiled the shadow-utils and PAM. My limit is still 32. Am I missing something - obvious? I did go ahead and upgrade to glibc-2.2-12 and kernel 2.4.3 (with edited headers) to no avail. This has been a really bad problem, I greatly appreciate any help at all. (thanks Jeff Garzik for your suggestion). BTW, please CC me directly. Stephen Stephen Burns wrote: > > Hey all, > > I have checked out the archives, and I found an old post regarding this. > The solution in the post, however, did not work for me. I am attempting to > raise the maximum 32 group per user limit on my 2.4.2 kernel. I patched > both linux/include/linux/limits.h and the asm-i386/param.h, replacing the > default "32" with "256." My glibc is 2.1.2. When I make clean, and > recompile the kernel, it boots fine but I am still limited to 32 groups. I > don't need to do anything with glibc since it is of the 2.1 or greater > category, correct? Any ideas, hints, tricks? Thanks a ton for your help, > please CC me as I've not been approved yet as a member of this list. You gotta change the task struct... -- Jeff Garzik | Sam: "Mind if I drive?" Building 1024 | Max: "Not if you don't mind me clawing at the dash MandrakeSoft | and shrieking like a cheerleader." - 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: [OT] Re: goodbye
On Mon, Apr 09, 2001 at 09:34:04PM +, Henning P. Schmiedehausen wrote: > Michael Peddemors <[EMAIL PROTECTED]> writes: > > >Uh... use their ISP relay service anyway??? > >I take my laptop all over, to lot's of my clients locations, and if I > >could relay through their servers, then I had better give them some good > >advice.. Some places I just pick an available IP and it might not be in > >the allowed relay list. And this happens when I am in M$ or Linux.. > > So, Mr. Admin, setup your laptop to use SSL to your SMTP and POP > server and authenticate with a client side certificate on your > laptop. Welcome to the 21st century. You may, however, need a little > more infrastructure than you can pull from your favourite distribution > box. RFC 2487STARTTLS RFC 2554SMTP-Auth, + M$ Exchange / + Netscape ( + a bunch of other authenticator methods ) Under encryption, plaintext username + password login. The IETF protocols DO NOT support plaintext login for obvious security reasons. No hazzles about autenticating by certificates. Availability of the feature is probably excidingly rare.. > Regards > Henning > -- > Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer > INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4-pre1 Unresolved symbols "strstr"
Jeff Chua wrote: > depmod version 2.4.5 > > Compiled 2.4.4-pre1 but running "depmod" generates a lot of these ... > > depmod: *** Unresolved symbols in > /lib/modules/2.4.4-pre1/kernel/drivers/char/ltmodem.o > depmod: strstr > depmod: *** Unresolved symbols in > /lib/modules/2.4.4-pre1/kernel/drivers/char/serial.o > depmod: strstr > depmod: *** Unresolved symbols in > /lib/modules/2.4.4-pre1/kernel/drivers/ide/ide-cd.o > depmod: strstr > depmod: *** Unresolved symbols in > /lib/modules/2.4.4-pre1/kernel/drivers/ide/ide-mod.o > depmod: strstr > depmod: *** Unresolved symbols in > /lib/modules/2.4.4-pre1/kernel/drivers/ide/ide-probe-mod.o > depmod: strstr > depmod: *** Unresolved symbols in > /lib/modules/2.4.4-pre1/pcmcia/xirc2ps_cs.o > depmod: strstr depmod: *** Unresolved symbols in /lib/modules/2.4.4-pre1/kernel/drivers/ide/ide-cd.o depmod: strstr depmod: *** Unresolved symbols in /lib/modules/2.4.4-pre1/kernel/drivers/ide/ide-tape.o depmod: strstr depmod: *** Unresolved symbols in /lib/modules/2.4.4-pre1/kernel/drivers/isdn/avmb1/capidrv.o depmod: strstr depmod: *** Unresolved symbols in /lib/modules/2.4.4-pre1/kernel/drivers/isdn/icn/icn.o depmod: strstr depmod: *** Unresolved symbols in /lib/modules/2.4.4-pre1/kernel/drivers/net/de4x5.o depmod: strstr depmod: *** Unresolved symbols in /lib/modules/2.4.4-pre1/kernel/drivers/net/depca.o depmod: strstr depmod: *** Unresolved symbols in /lib/modules/2.4.4-pre1/kernel/drivers/net/ewrk3.o depmod: strstr depmod: *** Unresolved symbols in /lib/modules/2.4.4-pre1/kernel/drivers/net/hamradio/baycom_epp.o depmod: strstr depmod: *** Unresolved symbols in /lib/modules/2.4.4-pre1/kernel/drivers/parport/parport.o depmod: strstr This is on a Cyrix P-166. Same with depmod 2.4.2 or 2.3.21 -- Nick Urbanik, Dept. of Computing and Mathematics Hong Kong Institute of Vocational Education (Tsing Yi) email: [EMAIL PROTECTED] Tel: (852) 2436 8576, (852) 2436 8579 Fax: (852) 2435 1406 pgp ID: 7529555D fingerprint: 53 B6 6D 73 52 EE 1F EE EC F8 21 98 45 1C 23 7B - 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: aic7xxx and 2.4.3 failures - fix, it is interrupt routing
G*rard Roudier insightfully opined.. > Looks like an IRQ problem to me. > I mean the kernel wants to change IRQ routing and just do the wrong job. Give the man a prize! After failing to work with 2.4.0, 2.4.1, 2.4.3, and 2.4.3-ac3 I enabled X86_UP_IOAPIC to stir up the interrupt code and it works. I'll keep one of these servers set aside for testing and see if I can't figure out a little more specifically what the problem is, but IOAPIC is fine. Thanks for the help all! -- Jim Studt, President The Federated Software Group, Inc. - 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: goodbye
On Tue, 10 Apr 2001, Matti Aarnio wrote: > Dave said "remove DUL", I did that. > VGER uses now RBL and RSS, no others. Thanks ! To come back to the spamfilter promise I made some time ago, people can now get a CVS tree with spam regular expressions and a script to generate a majordomo.cf from it ... Scripts to automatically generate configuration for other mailing list and mail delivery programs are very much welcome, as are people willing to help maintain the set of regexps. cvs -d :pserver:[EMAIL PROTECTED]:/home/CVS login password: cvs cvs -d :pserver:[EMAIL PROTECTED]:/home/CVS checkout spamfilter The (majordomo-run) mailing list [EMAIL PROTECTED] will be used for CVS updates and possibly discussion about this thing. I'm already using a procmail rule to automatically do a rebuild of NL.linux.org's majordomo.cf whenever something is changed to the CVS tree... regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - 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: goodbye
On Mon, Apr 09, 2001 at 02:50:55AM -0300, Rik van Riel wrote: > On Sun, 8 Apr 2001, David S. Miller wrote: > > Rik van Riel writes: > > > Anyway, since linux-kernel has chosen to not receive email from me > > Funny how this posting went through then... > > > > If it is specifically when you are sending mail from some other place, > > state so, don't make blanket statements which obviously are not wholly > > true. > > I'm temporarily using my ISP's smarthost. However, I'll turn this > off again soon because I'd rather stop with linux-kernel then give > in to the guilty-by-default attitude that comes with DUL. Dave said "remove DUL", I did that. VGER uses now RBL and RSS, no others. In few weeks time, I probably implement EXIMish "warn" feature. > Rik > -- > http://www.surriel.com/ > http://www.conectiva.com/ http://distro.conectiva.com.br/ /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Documentation glitch in 2.4
The Config help for kernel automount indicates that the pointer to user code is in the Documentation/Changes file for autofs. As far as I can tell that isn't the case. Since search engines seem to be better at finding the BSD and 2.2 software, it would be nice if the information was restored with all the other "get it here info." -- bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. - 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: aic7xxx and 2.4.3 failures
Looks like an IRQ problem to me. I mean the kernel wants to change IRQ routing and just do the wrong job. Ingo reported me a similar problem a couple of week ago that made failed the sym53c8xx driver. Looks very similar to this one with the kernel PCI code wanting to assign IRQ 11 to almost everything. Btw, I donnot know the cause of the problem since I am still expecting some reply following some suggestions from me. :-) Gerard. On Mon, 9 Apr 2001, Jim Studt wrote: > > > A typical startup with 6.1.9 proceeds like this... (6.1.10 hangs silently > > > after emitting the scsi0 and scsi1 adapter summaries, maybe it is > > > going through the same gyrations silently.) > > > > > > > Alan Cox directs... > > Try saying N to the AIC7xxx driver and Y to AIC7XXX_OLD and see if that works. > > This is important both because it might solve your problem for now but also > > because if the old driver works we can be fairly sure the bug is in the > > new adaptec driver and not elsewhere and triggered on it > > Using AIC7XXX_OLD does not work either. Different output > > SCSI subsystem driver Revision: 1.00 > PCI: Assigned IRQ 11 for device 00:0c.0 > PCI: The same IRQ used for device 00:0c.1 > PCI: Found IRQ 11 for device 00:0c.1 > PCI: The same IRQ used for device 00:0c.0 > (scsi0) found at PCI 0/12/0 > (scsi0) Wide Channel A, SCSI ID=7, 32/255 SCBs > (scsi0) Downloading sequencer code... 392 instructions downloaded > (scsi1) found at PCI 0/12/1 > (scsi1) Wide Channel B, SCSI ID=7, 32/255 SCBs > (scsi1) Downloading sequencer code... 392 instructions downloaded > scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0 > > scsi1 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0 > > scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 0, lun 0 >Inquiry 00 00 00 ff 00 > SCSI host 0 abort (pid 0) timed out - resetting > SCSI bus is being reset for host 0 channel 0. > SCSI host 0 channel 0 reset (pid 0) timed out - trying harder > SCSI bus is being reset for host 0 channel 0. > SCSI host 0 abort (pid 0) timed out - resetting > SCSI bus is being reset for host 0 channel 0. > SCSI host 0 channel 0 reset (pid 0) timed out - trying harder > SCSI bus is being reset for host 0 channel 0. > SCSI host 0 abort (pid 0) timed out - resetting > SCSI bus is being reset for host 0 channel 0. > .. > > > Since we are looking elsewhere now... I have tried PCI access mode > BIOS and Direct with no improvement. > > There is an unrecognized PCI bridge resource in the boot messages... > > CPU: L1 I cache: 16K, L1 D cache: 16K > CPU: L2 cache: 256K > Intel machine check architecture supported. > Intel machine check reporting enabled on CPU#0. > CPU serial number disabled. > CPU: Intel Pentium III (Coppermine) stepping 06 > Enabling fast FPU save and restore... done. > Enabling unmasked SIMD FPU exception support... done. > Checking 'hlt' instruction... OK. > POSIX conformance testing by UNIFIX > mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) > mtrr: detected mtrr type: Intel > PCI: Using configuration type 1 > PCI: Probing PCI hardware > Unknown bridge resource 0: assuming transparent > Unknown bridge resource 1: assuming transparent > Unknown bridge resource 2: assuming transparent > Unknown bridge resource 0: assuming transparent > Unknown bridge resource 1: assuming transparent > Unknown bridge resource 2: assuming transparent > PCI: Discovered primary peer bus ff [IRQ] > PCI: Using IRQ router PIIX [8086/7110] at 00:12.0 > > # lspci > 00:00.0 Host bridge: Intel Corporation 440GX - 82443GX Host bridge > 00:01.0 PCI bridge: Intel Corporation 440GX - 82443GX AGP bridge > 00:0c.0 SCSI storage controller: Adaptec 7896 > 00:0c.1 SCSI storage controller: Adaptec 7896 > 00:0e.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08) > 00:12.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) > 00:12.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) > 00:12.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) > 00:12.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02) > 00:14.0 VGA compatible controller: Cirrus Logic GD 5480 (rev 23) > 01:0f.0 PCI bridge: Digital Equipment Corporation DECchip 21150 (rev 06) > > I will go back and try 2.4.0 and 2.4.3-ac3 and see where that gets me. > > -- > Jim Studt, President > The Federated Software Group, Inc. > - > 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/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.3: still experiencing APIC-related hangs
On Fri, Mar 30, 2001 at 08:32:39AM -0800, [EMAIL PROTECTED] wrote:
> On Fri, Mar 30, 2001 at 02:32:24PM +0200, Frank de Lange wrote:
> > Subject says it all: 2.4.3 (unpatchaed) is still causing the dreaded
> > APIC-related hangs on SMP BX systems (Abit BP-6, maybe Gigabyte). I still need
> > to apply one of Maciej's patches to get rid of these hangs. The source comments
> > in arc/i386/kernel/apic.c ("If focus CPU is disabled then the hang goes away")
> > are incorrect, as the hang does not go away by simply disabling focus CPU. The
> > only way for me to get rid of the hangs is to apply patch-2.4.1-io_apic-46
> > (which does the LEVEL->EDGE->LEVEL triggered trick to 'free' the IO_APIC). I've
> > been running with this patch for quite some time now, and have not experienced
> > any problems with it. Maybe it it time to include it in the main kernel,
> > perhaps as a configurable option ("BROKEN_IO_APIC")?
Same for me.
> > Maciej, did you submit the patch to Linus? It really seems to solve the
> > (occurence of the) problems with these boards...
>
> Where is this patch found? I am not seeing it so far on kernel.org.
Attached, as I assume more people are interested in it ...
Regards,
--
Kurt Garloff <[EMAIL PROTECTED]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
patch-2.4.1-io_apic-46
diff -up --recursive --new-file linux-2.4.1.macro/arch/i386/kernel/apic.c
linux-2.4.1/arch/i386/kernel/apic.c
--- linux-2.4.1.macro/arch/i386/kernel/apic.c Wed Dec 13 23:54:27 2000
+++ linux-2.4.1/arch/i386/kernel/apic.c Mon Feb 12 16:11:15 2001
@@ -23,6 +23,7 @@
#include
#include
+#include
#include
#include
#include
@@ -270,7 +271,13 @@ void __init setup_local_APIC (void)
* PCI Ne2000 networking cards and PII/PIII processors, dual
* BX chipset. ]
*/
-#if 0
+ /*
+* Actually disabling the focus CPU check just makes the hang less
+* frequent as it makes the interrupt distributon model be more
+* like LRU than MRU (the short-term load is more even across CPUs).
+* See also the comment in end_level_ioapic_irq(). --macro
+*/
+#if 1
/* Enable focus processor (bit==0) */
value &= ~(1<<9);
#else
@@ -764,7 +771,7 @@ asmlinkage void smp_error_interrupt(void
apic_write(APIC_ESR, 0);
v1 = apic_read(APIC_ESR);
ack_APIC_irq();
- irq_err_count++;
+ atomic_inc(_err_count);
/* Here is what the APIC error bits mean:
0: Send CS error
diff -up --recursive --new-file linux-2.4.1.macro/arch/i386/kernel/i8259.c
linux-2.4.1/arch/i386/kernel/i8259.c
--- linux-2.4.1.macro/arch/i386/kernel/i8259.c Mon Nov 20 18:01:58 2000
+++ linux-2.4.1/arch/i386/kernel/i8259.cSun Feb 11 19:54:33 2001
@@ -12,6 +12,7 @@
#include
#include
+#include
#include
#include
#include
@@ -321,7 +322,7 @@ spurious_8259A_irq:
printk("spurious 8259A interrupt: IRQ%d.\n", irq);
spurious_irq_mask |= irqmask;
}
- irq_err_count++;
+ atomic_inc(_err_count);
/*
* Theoretically we do not have to handle this IRQ,
* but in Linux this does not cause problems and is
diff -up --recursive --new-file linux-2.4.1.macro/arch/i386/kernel/io_apic.c
linux-2.4.1/arch/i386/kernel/io_apic.c
--- linux-2.4.1.macro/arch/i386/kernel/io_apic.cSat Feb 3 12:05:49 2001
+++ linux-2.4.1/arch/i386/kernel/io_apic.c Tue Feb 13 19:59:55 2001
@@ -33,6 +33,8 @@
#include
#include
+#define APIC_LOCKUP_DEBUG
+
static spinlock_t ioapic_lock = SPIN_LOCK_UNLOCKED;
/*
@@ -122,8 +124,14 @@ static void add_pin_to_irq(unsigned int
static void name##_IO_APIC_irq (unsigned int irq) \
__DO_ACTION(R, ACTION, FINAL)
-DO_ACTION( __mask,0, |= 0x0001, io_apic_sync(entry->apic))/* mask = 1 */
-DO_ACTION( __unmask, 0, &= 0xfffe, ) /* mask = 0 */
+DO_ACTION( __mask, 0, |= 0x0001, io_apic_sync(entry->apic) )
+ /* mask = 1 */
+DO_ACTION( __unmask, 0, &= 0xfffe, )
+ /* mask = 0 */
+DO_ACTION( __mask_and_edge,0, = (reg & 0x7fff) | 0x0001, )
+ /* mask = 1, trigger = 0 */
+DO_ACTION( __unmask_and_level, 0, = (reg & 0xfffe) | 0x8000, )
+ /* mask = 0, trigger = 1 */
static void mask_IO_APIC_irq (unsigned int irq)
{
@@ -847,6 +855,8 @@ void /*__init*/ print_local_APIC(void *
v = apic_read(APIC_EOI);
printk(KERN_DEBUG "... APIC EOI: %08x\n", v);
+ v = apic_read(APIC_RRR);
+ printk(KERN_DEBUG "... APIC RRR: %08x\n", v);
Re: aic7xxx 6.1.10 and 2.4.4-pre1
>Apr 7 19:56:13 snap kernel: Vendor: SEAGATE Model: ST318275LWRev: > 0001 I seem to recall this being a very buggy firmware version. You should check with Seagate to see if they have something new. If this is the firmware I'm thinking of, the driver should perform correctly if you disable write caching. You can do this via the SCSI-Select menu for the controller. -- Justin - 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/
Version 6.1.11 of the aic7xxx driver availalbe
As always, the latest version of this driver is availalbe here: http://people.FreeBSD.org/~gibbs/linux/ This site now includes installation instructions, feature set, etc. The page is under construction - comments welcome. For the impatient: CHANGELOG: http://people.FreeBSD.org/~gibbs/linux/CHANGELOG 2.4.3-patch: http://people.FreeBSD.org/~gibbs/linux/linux-aic7xxx-6.1.11-2.4.3.patch.gz 2.2.19-patch: http://people.FreeBSD.org/~gibbs/linux/linux-aic7xxx-6.1.11-2.2.19.patch.gz -- Justin - 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: aic7xxx and 2.4.3 failures
I can add a "me too" to this thread. I began playing with 2.4 releases (again) at 2.4.2-ac23 and i can't manage to boot it properly, even the 2.4.3-ac2. I have an adaptec 2940U (aic7860 as driver tells me) and both drivers, old and new, dont work properly. Either i get request_module[scsi_hostadapter]: Root fs not mounted, and then what seems to be a random oops a couple of seconds later in the beginning of the init scripts, or, root fs doesnt get remounted rw, which is followed soon by some oopsen. I reported one back then ( http://boudicca.tux.org/hypermail/linux-kernel/2001week13/0077.html ). Looks weird ... have there been any changes around aic driver recently? I can try to write down some more oopsen if anyone is interested ... On the other side, 2.2.19 with new aic driver 6.1.10 is working just nice ... -- Jure Pecar - 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/
I can't read data from COM1
Hi all,
I write a sample code(user mode) to test the serial
driver.
I can open COM1 and write string to COM1.
But, when I want to read data from COM1, the program will
block at read function.
I trace the driver source code.
1.
When the program execute write operation, it will call
tty_write( ) at
/drivers/char/tty_io.c.
Then it will call gs_write( ) at
/drivers/char/general.c.
2.
When the program execute read operation,it will call
tty_read( ) at
/drivers/char/tty_io.c.
Then I don't know which function would be
called.
But it was blocked at operation which called
(tty->ldisc.read)(tty,file,buf,count), as the
following
/* Function tty_read( ) in
tty_io.c */
if
(tty->ldisc.read){ /* Program will be blocked
here */ i =
(tty->ldisc.read)(tty,file,buf,count); } else { /* Error
happened */ i =
-EIO; }
What parameter should I reset?
Thanks in advance.
Green
Re: aic7xxx and 2.4.3 failures
I confirm similar problems (see my message from yesterday). AIC7XXX_OLD also failed for me. I have tried aic 6.1.8 as well as 6.1.10. Both 2.4.0 under redhat 7.0 and 2.4.1 as shipped by redhat wolverine work. As have all earlier versions going back to 2.3.xx and 2.2.x On Mon, Apr 09, 2001 at 03:33:47PM -0500, Jim Studt wrote: > > > A typical startup with 6.1.9 proceeds like this... (6.1.10 hangs silently > > > after emitting the scsi0 and scsi1 adapter summaries, maybe it is > > > going through the same gyrations silently.) > > > > > > > Alan Cox directs... > > Try saying N to the AIC7xxx driver and Y to AIC7XXX_OLD and see if that works. > > This is important both because it might solve your problem for now but also > > because if the old driver works we can be fairly sure the bug is in the > > new adaptec driver and not elsewhere and triggered on it > > Using AIC7XXX_OLD does not work either. Different output > > SCSI subsystem driver Revision: 1.00 > PCI: Assigned IRQ 11 for device 00:0c.0 > PCI: The same IRQ used for device 00:0c.1 > PCI: Found IRQ 11 for device 00:0c.1 > PCI: The same IRQ used for device 00:0c.0 > (scsi0) found at PCI 0/12/0 > (scsi0) Wide Channel A, SCSI ID=7, 32/255 SCBs > (scsi0) Downloading sequencer code... 392 instructions downloaded > (scsi1) found at PCI 0/12/1 > (scsi1) Wide Channel B, SCSI ID=7, 32/255 SCBs > (scsi1) Downloading sequencer code... 392 instructions downloaded > scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0 > > scsi1 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0 > > scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 0, lun 0 >Inquiry 00 00 00 ff 00 > SCSI host 0 abort (pid 0) timed out - resetting > SCSI bus is being reset for host 0 channel 0. > SCSI host 0 channel 0 reset (pid 0) timed out - trying harder > SCSI bus is being reset for host 0 channel 0. > SCSI host 0 abort (pid 0) timed out - resetting > SCSI bus is being reset for host 0 channel 0. > SCSI host 0 channel 0 reset (pid 0) timed out - trying harder > SCSI bus is being reset for host 0 channel 0. > SCSI host 0 abort (pid 0) timed out - resetting > SCSI bus is being reset for host 0 channel 0. > ... > > > Since we are looking elsewhere now... I have tried PCI access mode > BIOS and Direct with no improvement. > > There is an unrecognized PCI bridge resource in the boot messages... > > CPU: L1 I cache: 16K, L1 D cache: 16K > CPU: L2 cache: 256K > Intel machine check architecture supported. > Intel machine check reporting enabled on CPU#0. > CPU serial number disabled. > CPU: Intel Pentium III (Coppermine) stepping 06 > Enabling fast FPU save and restore... done. > Enabling unmasked SIMD FPU exception support... done. > Checking 'hlt' instruction... OK. > POSIX conformance testing by UNIFIX > mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) > mtrr: detected mtrr type: Intel > PCI: Using configuration type 1 > PCI: Probing PCI hardware > Unknown bridge resource 0: assuming transparent > Unknown bridge resource 1: assuming transparent > Unknown bridge resource 2: assuming transparent > Unknown bridge resource 0: assuming transparent > Unknown bridge resource 1: assuming transparent > Unknown bridge resource 2: assuming transparent > PCI: Discovered primary peer bus ff [IRQ] > PCI: Using IRQ router PIIX [8086/7110] at 00:12.0 > > # lspci > 00:00.0 Host bridge: Intel Corporation 440GX - 82443GX Host bridge > 00:01.0 PCI bridge: Intel Corporation 440GX - 82443GX AGP bridge > 00:0c.0 SCSI storage controller: Adaptec 7896 > 00:0c.1 SCSI storage controller: Adaptec 7896 > 00:0e.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08) > 00:12.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) > 00:12.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) > 00:12.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) > 00:12.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02) > 00:14.0 VGA compatible controller: Cirrus Logic GD 5480 (rev 23) > 01:0f.0 PCI bridge: Digital Equipment Corporation DECchip 21150 (rev 06) > > I will go back and try 2.4.0 and 2.4.3-ac3 and see where that gets me. > > -- > Jim Studt, President > The Federated Software Group, Inc. > - > 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/ - 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: No 100 HZ timer !
On Mon, 09 Apr 2001, Alan Cox wrote: > > this is one of linux biggest weaknesses. the fixed interval timer is a > > throwback. it should be replaced with a variable interval timer with interrupts > > on demand for any system with a cpu sane/modern enough to have an on-chip > > interrupting decrementer. (i.e just about any modern chip) > > Its worth doing even on the ancient x86 boards with the PIT. It does require > some driver changes since > > > while(time_before(jiffies, we_explode)) > poll_things(); > > no longer works > It would be great if this could be one of the 2.5 goals/projects. it would make all sorts of fun and useful timed event services easier to implement and provide (potentially) microsecond resolution as opposed to the current 10Ms. plus, we would only get one "sysclock" timer interrupt per process quantum instead of 10. -- /*** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - 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: aic7xxx and 2.4.3 failures
> > A typical startup with 6.1.9 proceeds like this... (6.1.10 hangs silently > > after emitting the scsi0 and scsi1 adapter summaries, maybe it is > > going through the same gyrations silently.) > > > Alan Cox directs... > Try saying N to the AIC7xxx driver and Y to AIC7XXX_OLD and see if that works. > This is important both because it might solve your problem for now but also > because if the old driver works we can be fairly sure the bug is in the > new adaptec driver and not elsewhere and triggered on it Using AIC7XXX_OLD does not work either. Different output SCSI subsystem driver Revision: 1.00 PCI: Assigned IRQ 11 for device 00:0c.0 PCI: The same IRQ used for device 00:0c.1 PCI: Found IRQ 11 for device 00:0c.1 PCI: The same IRQ used for device 00:0c.0 (scsi0) found at PCI 0/12/0 (scsi0) Wide Channel A, SCSI ID=7, 32/255 SCBs (scsi0) Downloading sequencer code... 392 instructions downloaded (scsi1) found at PCI 0/12/1 (scsi1) Wide Channel B, SCSI ID=7, 32/255 SCBs (scsi1) Downloading sequencer code... 392 instructions downloaded scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0 scsi1 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0 scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 0, lun 0 Inquiry 00 00 00 ff 00 SCSI host 0 abort (pid 0) timed out - resetting SCSI bus is being reset for host 0 channel 0. SCSI host 0 channel 0 reset (pid 0) timed out - trying harder SCSI bus is being reset for host 0 channel 0. SCSI host 0 abort (pid 0) timed out - resetting SCSI bus is being reset for host 0 channel 0. SCSI host 0 channel 0 reset (pid 0) timed out - trying harder SCSI bus is being reset for host 0 channel 0. SCSI host 0 abort (pid 0) timed out - resetting SCSI bus is being reset for host 0 channel 0. ... Since we are looking elsewhere now... I have tried PCI access mode BIOS and Direct with no improvement. There is an unrecognized PCI bridge resource in the boot messages... CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU serial number disabled. CPU: Intel Pentium III (Coppermine) stepping 06 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 0: assuming transparent Unknown bridge resource 1: assuming transparent Unknown bridge resource 2: assuming transparent Unknown bridge resource 0: assuming transparent Unknown bridge resource 1: assuming transparent Unknown bridge resource 2: assuming transparent PCI: Discovered primary peer bus ff [IRQ] PCI: Using IRQ router PIIX [8086/7110] at 00:12.0 # lspci 00:00.0 Host bridge: Intel Corporation 440GX - 82443GX Host bridge 00:01.0 PCI bridge: Intel Corporation 440GX - 82443GX AGP bridge 00:0c.0 SCSI storage controller: Adaptec 7896 00:0c.1 SCSI storage controller: Adaptec 7896 00:0e.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08) 00:12.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) 00:12.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) 00:12.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) 00:12.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02) 00:14.0 VGA compatible controller: Cirrus Logic GD 5480 (rev 23) 01:0f.0 PCI bridge: Digital Equipment Corporation DECchip 21150 (rev 06) I will go back and try 2.4.0 and 2.4.3-ac3 and see where that gets me. -- Jim Studt, President The Federated Software Group, Inc. - 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: [CHECKER] __init functions called by non-__init
Hi!
> 1. The best case: an init function calls a non-init, which in
> turn calls an init:
>
> void __init probe() { a(); }
> void a() { b(); }
> void __init b() { ... }
> in this case, is the missing __init on 'a' only a performance
> bug in that a's code won't be freed up?
...not neccesarily an error. If a() is being used to do stuff needed at
runtime, and only calls b() at initialzation.
> On the other hand, if I understood the rules right, this next one looks like
> a more exciting error, since an __exit routine is calling an __init routine:
Actually, it is right for subtle reasons:
__exit is only used in module case. And in module case __init functions are
not freed.
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
-
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/
Sound problem with 2.2.19
Originally to: All I am sorry if this is old news but I have not seen any mention of it in the list. I keep getting "kernel: Sound error: Couldn't allocate DMA buffer" in my syslog. However sound was working until this morning. The machine uptime is below :) The PC is a IBM PS/2 486DX2, with an AWE32 with 256k. The PC is fitted with 16mb of ram. I have never reported a problem before so excuse if it is a bit strange. Sean -- GNUPG ID 92B9D0CF| YAIM: thecivvie| Fidonet and BBS ICQ: 679813 | Homepage: http://www.tcob1.net | Newsportal at Linux User: #124682 | AIM: tcobone | tcob1.uklinux.net My last power cut was 3d, 4h and 25m ago on Linux 2.2.19. <-> Information This message originated from a Fidonet system and was gated at There Can Only be 1 (http://www.tcob1.net) For information of Fidonet visit http://www.fidonet.org Please do not respond direct to this message but via the - 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: ISIcom cards by Multi-tech
> > I did a quick port of the old driver over (it wasnt very hard) and people then > > added additional bits of support later. > > > > multitech never sent me many updates > > O well. I thought it went this way > > Do you have sort of a 'patch' from your port? I could take this as a > guideline for what has to be changed from 2.2 to 2.4. If I compare the > 2.4 driver to the actual 2.2 one, there are far too much differences for > me... I dontt. Other than comparing the 2.2 and 2.4 driver - 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: aic7xxx and 2.4.3 failures
> A typical startup with 6.1.9 proceeds like this... (6.1.10 hangs silently > after emitting the scsi0 and scsi1 adapter summaries, maybe it is > going through the same gyrations silently.) > Try saying N to the AIC7xxx driver and Y to AIC7XXX_OLD and see if that works. This is important both because it might solve your problem for now but also because if the old driver works we can be fairly sure the bug is in the new adaptec driver and not elsewhere and triggered on it - 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: No 100 HZ timer !
> this is one of linux biggest weaknesses. the fixed interval timer is a > throwback. it should be replaced with a variable interval timer with interrupts > on demand for any system with a cpu sane/modern enough to have an on-chip > interrupting decrementer. (i.e just about any modern chip) Its worth doing even on the ancient x86 boards with the PIT. It does require some driver changes since while(time_before(jiffies, we_explode)) poll_things(); no longer works - 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/
messages with ide-scsi
Hi ! I'm installing a CD burner and I've setup the ide-scsi, while checking the setup, I got the following messages. What does this means, please ? System is : --- Linux debian-f5ibh 2.2.19 #1 lun avr 9 18:33:18 CEST 2001 i586 unknown Gnu C 2.95.2 Gnu make 3.79.1 binutils 2.9.5.0.37 util-linux 2.10f modutils 2.4.5 e2fsprogs 1.19 PPP2.4.0 Linux C Library2.1.3 ldd: version 1.9.11 Procps 2.0.6 Net-tools 1.54 Console-tools 0.2.3 Sh-utils 2.0 Modules Loaded sg ide-scsi ppa scsi_mod parport_pc parport af_packet scc ax25 autofs lockd sunrpc usbcore w83781d sensors i2c-isa i2c-core unix And here are the messages : --- [root@debian-f5ibh] ~ # cdrecord -scanbus ALI15X3: MultiWord DMA enabled ALI15X3: MultiWord DMA enabled scsi1 : SCSI host adapter emulation for IDE ATAPI devices scsi : 2 hosts. Vendor: GoldStar Model: CD-RW CED-8083B Rev: 1.05 Type: CD-ROM ANSI SCSI revision: 02 Vendor: CREATIVE Model: CD3621E ZC100Rev: 1.00 Type: CD-ROM ANSI SCSI revision: 02 Using libscg version 'schily-0.1' Cdrecord 1.8 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jörg Schilling Using libscg version 'schily-0.1' scsibus0: 0,0,0 0) 'GoldStar' 'CD-RW CED-8083B ' '1.05' Removable CD-ROM ide-scsi: The scsi wants to send us more data than expected - discarding data ide-scsi: The scsi wants to send us more data than expected - discarding data ide-scsi: The scsi wants to send us more data than expected - discarding data ide-scsi: The scsi wants to send us more data than expected - discarding data ide-scsi: The scsi wants to send us more data than expected - discarding data ide-scsi: The scsi wants to send us more data than expected - discarding data ide-scsi: The scsi wants to send us more data than expected - discarding data ide-scsi: The scsi wants to send us more data than expected - discarding data ide-scsi: The scsi wants to send us more data than expected - discarding data 0,1,0 1) 'CREATIVE' 'CD3621E ZC100 ' '1.00' Removable CD-ROM 0,2,0 2) * 0,3,0 3) * 0,4,0 4) * 0,5,0 5) * 0,6,0 6) * 0,7,0 7) * Regards Jean-Luc - 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: Processes hanging in D state in 2.4.3 - any findings?
> I have seen several messages posted to l-k about people reporting > processes (mozilla most of the time) hanging in the D state in 2.4.3, > but I haven't seen someone posting a possible explanation or solution > to the problem. > Anyone knows where does the problem lie, or a workaround for the > problem? I hate going through the fsck that happens when umount fails > because processes are in the D state... 2.2.19 or wait for 2.4.4pre soon to fix the semaphore problem that causes this - 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: Re: nfs performance at high loads
> Thanks for the inputs.. But, if we cannot move back to 2.2.19 > and need to stick with 2.4.0 for our own reasons concerning the > work underway, would it be possible to give us a pointer us to > the list of issues related to this problem in the vm, so that we > may attempt to try and get some fixes or workarounds done - > well, they may or may not be accepted into mainstream linux for > various reasons, but we may need to get them fixed to ship our > stuff and may plan to do so.. See the linux-mm list. Or talk to Rik van Riel <[EMAIL PROTECTED]> - 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: Question on accessing /proc
Srinivasan Venkatraman wrote: > I am new to this list. I did go through the FAQ before posting this > question. I have a specific requirment - creating,modifying and deleting > data structures inside the kernel values of which will be passed by an > user application. I know we could do this by writing a system call or by > ioctl command to a character device. My question is can we do this by > writing to /proc file system ? Can we actually create, modify and delete > data structures by accessing this file system ? You could definitely use procfs, but it sounds like your example would be complex. Lately mounting filesystems has become a cheap operation in Linux. Mount/umount is also a convenient synchronization point. So, maybe consider implementing your own tiny filesystems - a data filesystem, where you mmap(2)/read(2)/write(2) data values, and a control filesystem, where you control the system and manipulate data values. That way, you can use standard Unix syscalls, standard Unix tools and standard Unix permissions to accomplish your domain-specific task. -- Jeff Garzik | Sam: "Mind if I drive?" Building 1024 | Max: "Not if you don't mind me clawing at the dash MandrakeSoft | and shrieking like a cheerleader." - 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: ISIcom cards by Multi-tech
Alan Cox wrote: > > > As multitech seems not to provide a driver for 2.4, someone must have > > ported the 2.2 driver to 2.4. I'd like to talk to this person, and help > > merging the 2.2 updates to 2.4. > > I did a quick port of the old driver over (it wasnt very hard) and people then > added additional bits of support later. > > multitech never sent me many updates O well. I thought it went this way Do you have sort of a 'patch' from your port? I could take this as a guideline for what has to be changed from 2.2 to 2.4. If I compare the 2.4 driver to the actual 2.2 one, there are far too much differences for me... bye, Michael -- netWorks Vox: +43 316 692396 Michael Reinelt Fax: +43 316 692343 Geisslergasse 4 GSM: +43 676 3079941 A-8045 Graz, Austria e-mail: [EMAIL PROTECTED] - 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/
Question on accessing /proc
Hi, I am new to this list. I did go through the FAQ before posting this question. I have a specific requirment - creating,modifying and deleting data structures inside the kernel values of which will be passed by an user application. I know we could do this by writing a system call or by ioctl command to a character device. My question is can we do this by writing to /proc file system ? Can we actually create, modify and delete data structures by accessing this file system ? Any pointers will be appreciated. Thanks, Srini. - 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: goodbye
Alan Cox wrote: > > I really would like to run "ORBS" on my incoming-mail-server. However > > I find it unacceptable to be rejecting Email from possibly legitimate > > clients. So Adding an "relay is listed on orbs" line would allow me to > > sort this into a low priority "probably spam" mailbox, just like I'd > > do with those tagged as such by LKML. > > So run exim. It has supported this for years Someone suggested "rblcheck". Installed, works. Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots. - 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/
aic7xxx and 2.4.3 failures
I've got a trio of identical PIII machines all failing with aic7xxx under
2.4.3. I've tried both aic7xxx 6.1.9 and 6.1.10 in addition to the one
in 2.4.3 (6.1.5?). These machines work fine under 2.2.18pre21.
I'm looking for any ideas or suggestions on how to fix this.
(Ok, honestly I'm hoping someone will say `you fool, read this message',
but I don't have high hopes for that.)
A typical startup with 6.1.9 proceeds like this... (6.1.10 hangs silently
after emitting the scsi0 and scsi1 adapter summaries, maybe it is
going through the same gyrations silently.)
SCSI subsystem driver Revision: 1.00
request_module[scsi_hostadapter]: Root fs not mounted
request_module[scsi_hostadapter]: Root fs not mounted
PCI: Assigned IRQ 11 for device 00:0c.0
PCI: The same IRQ used for device 00:0c.1
PCI: Found IRQ 11 for device 00:0c.1
PCI: The same IRQ used for device 00:0c.0
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.9
aic7896/97: Wide Channel A, SCSI Id=7, 32/255 SCBs
scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.9
aic7896/97: Wide Channel B, SCSI Id=7, 32/255 SCBs
scsi0:0:0:0: Attempting to queue an ABORT message
scsi0:0:0:0: Command already completed
aic7xxx_abort returns 8194
scsi0:0:0:0: Attempting to queue an ABORT message
scsi0:0:0:0: Device is active, asserting ATN
Recovery code sleeping
Recovery code awake
Timer Expired
aic7xxx_abort returns 8195
scsi0:0:0:0: Attempting to queue a TARGET RESET message
aic7xxx_dev_reset returns 8195
Recovery SCB completes
scsi0:0:0:0: Attempting to queue an ABORT message
ahc_intr: HOST_MSG_LOOP bad phase 0x0
scsi0:0:0:0: Cmd aborted from QINFIFO
aic7xxx_abort returns 8194
scsi: device set offline - not ready or command retry failed after bus reset: host 0
channel 0 id 0 lun 0
It repeats this for each ID for which a device exists. There actually
is a unit 0 and 1 on this bus. The error stream is slightly different
for unused IDs...
scsi0:0:2:0: Attempting to queue an ABORT message
scsi0:0:2:0: Command already completed
aic7xxx_abort returns 8194
scsi0:0:2:0: Attempting to queue an ABORT message
scsi0:0:2:0: Command already completed
aic7xxx_abort returns 8194
scsi0:0:2:0: Attempting to queue a TARGET RESET message
scsi0:0:2:0: Is not an active device
aic7xxx_dev_reset returns 8194
scsi0:0:2:0: Attempting to queue an ABORT message
scsi0:0:2:0: Command already completed
aic7xxx_abort returns 8194
scsi0:0:2:0: Attempting to queue an ABORT message
scsi0:0:2:0: Command already completed
aic7xxx_abort returns 8194
scsi: device set offline - not ready or command retry failed after bus reset: host 0
channel 0 id 2 lun 0
After failing on all 32 potential IDs at something like 47 seconds per
ID the boot proceeds and fails to mount the root partition which is on
these disks.
Other potentially useful information gathered from 2.2.18pre21...
/proc/pci says
00:0c.1 SCSI storage controller: Adaptec 7896
Subsystem: Adaptec: Unknown device 0053
Flags: bus master, medium devsel, latency 64, IRQ 11
BIST result: 00
I/O ports at 2800
Memory at f4102000 (64-bit, non-prefetchable)
Capabilities: [dc] Power Management version 1
dotdot-new:~# cat /proc/scsi/aic7xxx/0
Adaptec AIC7xxx driver version: 5.1.31/3.2.4
Compile Options:
TCQ Enabled By Default : Disabled
AIC7XXX_PROC_STATS : Enabled
AIC7XXX_RESET_DELAY: 15
Adapter Configuration:
SCSI Adapter: Adaptec AIC-7896/7 Ultra2 SCSI host adapter
Ultra-2 LVD/SE Wide Controller Channel A at PCI 0/12/0
PCI MMAPed I/O Base: 0xf4101000
Adapter SEEPROM Config: SEEPROM found and used.
Adaptec SCSI BIOS: Enabled
IRQ: 11
SCBs: Active 0, Max Active 2,
Allocated 15, HW 32, Page 255
Interrupts: 3366
BIOS Control Word: 0x18a6
Adapter Control Word: 0x1c5e
Extended Translation: Enabled
Disconnect Enable Flags: 0x
Ultra Enable Flags: 0x
Tag Queue Enable Flags: 0x
Ordered Queue Tag Flags: 0x
Default Tag Queue Depth: 8
Tagged Queue By Device array for aic7xxx host instance 0:
{255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255}
Actual queue depth per device for aic7xxx host instance 0:
{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}
--
Jim Studt, President
The Federated Software Group, Inc.
-
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: goodbye
> The other exception is untestable-netblocks.orbs.org, which blocks > everything it cannot test and is just as bad as DUL. untestable-netblocks is the killer for 20% of the actual spam I get (almost entirely from rr.com) > Anyway, since linux-kernel has chosen to not receive email from me > I won't bother answering VM bugreports or anything here. It's up to > Matti and Davem to decide how useful a place linux-kernel will be. Thats ok. Andrea will I am sure be happy to take over as maintainer - 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: Unresolved symbol in 2.4.4p1, ia32
On Mon, Apr 09, 2001 at 07:58:23PM +0100, Alan Cox wrote: > > depmod: *** Unresolved symbols in > > /lib/modules/2.4.4-pre1/kernel/drivers/ide/ide-cd.o > > depmod: strstr > > > > depmod: *** Unresolved symbols in > > /lib/modules/2.4.4-pre1/kernel/drivers/parport/parport.o > > depmod: strstr > > That'll be from my patches. Now I am back I'll check over the stuff I sent > Linus and see what escaped/got dropped/didnt get sent. I suspect its a missing > EXPORT entry Yep. ftp://ftp.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.4pre1/strstr-1 Andrea - 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/
[OT] Re: goodbye
Uh... use their ISP relay service anyway??? I take my laptop all over, to lot's of my clients locations, and if I could relay through their servers, then I had better give them some good advice.. Some places I just pick an available IP and it might not be in the allowed relay list. And this happens when I am in M$ or Linux.. And sometimes, I even go to locations where they can't tell me their ISP's SMTP mailer.. Not to mention, I shouln't have to reset my configuration for each location I happen to be at.. The point is, if it is a pain, then people will be less likely to contribute.. My point was that.. the LKML shouldn't make it tough for legimate posters.. And if someone's purpose is to spam the list, they can get around DULS easy enough.. On 08 Apr 2001 02:32:28 +0300, Matti Aarnio wrote: > On Tue, Apr 03, 2001 at 06:14:33PM -0700, Michael Peddemors wrote: > > This would be a shame, as he has been a valuable resource.. > > Why has the list become more restrictive? > The incentive behind the DUL is to force users not to post > straight out to the world, but to use their ISP's servers > for outbound email --- normal M$ users do that, after all. > Only spammers - and UNIX powerusers - want to post directly > to the world from dialups. And UNIX powerusers should know > better, and be able to use ISP relay service anyway. > -- "Catch the Magic of Linux..." Michael Peddemors - Senior Consultant LinuxAdministration - Internet Services NetworkServices - Programming - Security WizardInternet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604)589-0037 Beautiful British Columbia, Canada - 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: Zero Copy IO
> advantageous to enable zero copy IO than copy_from_user() and copy_to_user > () all the data. Other OS such as AIX and OS2 have kernel functions that > can be used to accomplish such a task. Has any ground work been done in > Linux 2.4 to enable "zero copying IO"? kiovecs support this. Note that the current kiovec has problems when it comes to certain kinds of latency critical use and the 2.5 kernel meeting hashed out some big changes here. But for 2.4 the kiovecs are there - 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: PROBLEM: select() on TCP socket sleeps for 1 tick even if data available
"Stephen D. Williams" <[EMAIL PROTECTED]> writes: > An old thread, but important to get these fundamental performance > numbers up there: > > 2.4.2 on an 800mhz PIII Sceptre laptop w/ 512MB ram: > > elapsed time for 10 pingpongs is > 3.81327 > 10/3.81256 > ~26229.09541095746689888159 > 1/.379912 > ~26321.88506812103855629724 > > 26300 compares to 8000/sec. quite well ;-) You didn't give specs for > your test machine unfortunately. > > Since this tests both 'sides' of an application communication, it > indicates a 'null transaction' rate of twice that. > > This was typical cpu usage on a triple run of 1: > CPU states: 7.2% user, 92.7% system, 0.0% nice, 0.0% idle I seemed to miss the original post, so I can't really comment on the tests. However... > Michael Lindner wrote: > > > > OK, 2.4.0 kernel installed, and a new set of numbers: > > > > testkernel ping-pongs/s. @ total CPU util w/SOL_NDELAY > > sample (2 skts) 2.2.18 100 @ 0.1% 800 @ 1% > > sample (1 skt) 2.2.18 8000 @ 100% 8000 @ 50% > > real app2.2.18 100 @ 0.1% 800 @ 1% > > > > sample (2 skts) 2.4.0 8000 @ 50% 8000 @ 50% > > sample (1 skt) 2.4.0 1 @ 50% 1 @ 50% > > real app2.4.0 1200 @ 50% 1200 @ 50% > > > > real appWindows 2K 4000 @ 100% > > > > The two points that still seem strange to me are: > > > > 1. The 1 socket case is still 25% faster than the 2 socket case in 2.4.0 > > (in 2.2.18 the 1 socket case was 10x faster). > > > > 2. Linux never devotes more than 50% of the CPU (average over a long > > run) to the two processes (25% to each process, with the rest of the > > time idle). > > > > I'd really love to show that Linux is a viable platform for our SW, and > > I think it would be doable if I could figure out how to get the other > > 50% of my CPU involved. An "strace -rT" of the real app on 2.4.0 looks > > like this for each ping/pong. > > > > 0.052371 send(7, "\0\0\0 > > \177\0\0\1\3243\0\0\0\2\4\236\216\341\0\0\v\277"..., 32, 0) = 32 > > <0.000529> > > 0.000882 rt_sigprocmask(SIG_BLOCK, ~[], [RT_0], 8) = 0 <0.21> > > 0.000242 rt_sigprocmask(SIG_SETMASK, [RT_0], NULL, 8) = 0 > > <0.21> > > 0.000173 select(8, [3 4 6 7], NULL, NULL, NULL) = 1 (in [6]) > > <0.47> > > 0.000328 read(6, "\0\0\0 ", 4) = 4 <0.31> > > 0.000179 read(6, > > "\177\0\0\1\3242\0\0\0\2\4\236\216\341\0\0\7\327\177\0\0"..., 28) = 28 > > <0.75> The strace here shows select() with an infinite timeout, you're numbers will be much better if you do (pseudo code)... struct timeval zerotime; zerotime.tv_sec = 0; zerotime.tv_usec = 0; if (!(ret = select( ... , ))) ret = select( ... , NULL); ...basically you completely miss the function call for __pollwait() inside poll_wait (include/linux/poll.h in the linux sources, with __pollwait being in fs/select.c). -- # James Antill -- [EMAIL PROTECTED] :0: * ^From: .*james@and\.org /dev/null - 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: goodbye
> I really would like to run "ORBS" on my incoming-mail-server. However > I find it unacceptable to be rejecting Email from possibly legitimate > clients. So Adding an "relay is listed on orbs" line would allow me to > sort this into a low priority "probably spam" mailbox, just like I'd > do with those tagged as such by LKML. So run exim. It has supported this for years Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PS/2 ESDI
All,
OK, Helge is of course correct here. I will get a new patch out tonight.
Basically, the ending = -1; needs to be preceded by an else.
(I think so anyway, as I don't have access to that machine right now.)
Hal Duston
[EMAIL PROTECTED]
On Mon, 9 Apr 2001, Helge Deller wrote:
> Hi Hal,
>
> I don't have any ps2esdi devices, but while I was looking at your patch I
> found:
>
> case INT_CMD_COMPLETE:
> @@ -893,13 +879,9 @@
> printk("%s: timeout reading status word\n", DEVICE_NAME);
> outb((int_ret_code & 0xe0) | ATT_EOI, ESDI_ATTN);
> outb(CTRL_ENABLE_INTR, ESDI_CONTROL);
> - if ((++CURRENT->errors) < MAX_RETRIES)
> - do_ps2esdi_request(NULL);
> - else {
> - end_request(FAIL);
> - if (!QUEUE_EMPTY)
> - do_ps2esdi_request(NULL);
> - }
> + if ((++CURRENT->errors) >= MAX_RETRIES)
> + ending = FAIL;
> + ending = -1;
> break;
> }
>
> Just a thought:
> in this if().. clause ending may get the FAIL value, but directly afterwards
> it is set to -1 again
> You have this two times in your patch.
>
> Greetings,
> Helge.
-
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: Unresolved symbol in 2.4.4p1, ia32
> depmod: *** Unresolved symbols in > /lib/modules/2.4.4-pre1/kernel/drivers/ide/ide-cd.o > depmod: strstr > > depmod: *** Unresolved symbols in > /lib/modules/2.4.4-pre1/kernel/drivers/parport/parport.o > depmod: strstr That'll be from my patches. Now I am back I'll check over the stuff I sent Linus and see what escaped/got dropped/didnt get sent. I suspect its a missing EXPORT entry - 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: ISIcom cards by Multi-tech
> As multitech seems not to provide a driver for 2.4, someone must have > ported the 2.2 driver to 2.4. I'd like to talk to this person, and help > merging the 2.2 updates to 2.4. I did a quick port of the old driver over (it wasnt very hard) and people then added additional bits of support later. multitech never sent me many updates - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Ext2 Directory Index - File Structure
Daniel, you write:
> For the past several weeks I have been developing a directory index
> facility for Ext2, with good results so far. This note describes the
> on-disk format of the new index.
Finally starting to test your last release, and you make a new one... ;-)
> Needless to say, the new code no longer clears this bit but uses it as
> it was intended, to flag the presence of an index on a directory. If a
> partition has been mounted with the -o index[2] option enabled then each
> new directory is created with the EXT2_INDEX_FL set.
Are you going to go to a COMPAT flag before final release? This is
pretty much needed for e2fsck to be able to detect/correct indexes.
> struct dx_root
> {
> struct dx_root_info
> {
> struct fake_dirent fake1;
> char dot1[4];
> struct fake_dirent fake2;
> char dot2[4];
> u8 info_length; /* 8 */
> u8 hash_version; /* 0 */
> u8 indirect_levels
> u8 unused_flags;
> le_u32 reserved_zero;
> }
> info;
> struct dx_entry entries[0];
> };
One thing I was thinking about the root entry - for compatibility with 2.0
and earlier kernels (which don't clear INDEX_FL) there is a simple solution:
- deleted dirents do not pose any problems, because a hash index is no
guarantee that a specific dirent exists, only a range of possible entries
- adding a dirent will _always_ go into the first empty block (which is the
index root block), and overwrite the dx_root_info data after "." and ".."
In the latter case (and also in the case of data corruption), it is useful
to have some sort of integrity check within dx_root_info. If a dirent
overwrote the root index block, the first 4 bytes of the dirent after
"." and ".." would be an inode number, this could be anything and is not
very useful for detecting if it is a valid number or not. However, if you
put the "reserved_zero" field first and swap the order of "hash_version"
and "info_length", then "info_length" and "hash_version" will overlap with
the "rec_len" field of a new dirent. If (hash_version & 3) is always true,
a valid "rec_len" is always a multiple of 4, so it is possible to detect if
the dx_root_info has been overwritten by an old version of ext2 code. So:
struct dx_root_info {
struct fake_dirent fake1;
char dot1[4];
struct fake_dirent fake2;
char dot2[4];
/* __u32 inode; */ le_u32 reserved_zero;
/* __u16 rec_len lo */ u8 hash_version; /* 1, or 2, or 3, but not 0 or 4 */
/* __u16 rec_len hi */ u8 info_length; /* 8 */
u8 indirect_levels
u8 unused_flags;
} info;
It will also be easy to detect if reserved_zero is changed, because zero is
not a valid inode number. We can't rely on fake2's rec_len in case a dir
entry was added and then deleted (corrupting dx_root_info, but leaving
fake1 and fake2 as they should be).
> The high four bits of the block pointer field are reserved for use by
> a coalesce-on-delete feature which may be implemented in the future.
> The remaining 28 bits are capable of indexing up to 1TB per directory
> file. (Perhaps I should coopt 8 bits instead of 4.)
Might be worthwhile, even if you don't use all of the bits for coalesce
flags. Nothing better than having free space for future expansion. Even
for a 1kB block filesystem, this would give us directories up to 16GB, at
worst case about 32M 256-character entries, average case 595M 9-to-12-character
names. Having 24 bits for 4kB block (64GB) directories gives us worst-case
117M 256-character entries, and average case 2.2B 9-to-12 character names.
Assumes 50% full leaf blocks for worst case, 70% full for average case.
For that matter, I'm not even sure if ext2 supports directory files larger
than 2GB? Anyone? I'm not 100% sure, but it may be that e2fsck considers
directories >2GB as invalid.
> Thus, directory leafs will average no more than 75% full and typically
> a few points less than that since the hash function never produces a
> perfectly uniform distribution. (The better the hash function, the
> closer we get to 75%; we are currently at 71%.)
Have you been testing this with different kinds of input for filenames,
or only synthetic input data? One interesting dataset would be to get
the filename generation code from sendmail (for /var/spool/mqueue) and/or
inn and/or squid to see how those names are hashed. These are legitimate
applications which tend to store lots of files in a single directory.
> It is quite likely that the hash function will be improved in the
> future, therefore a hash function version field is included in the root
> header. If the current code
Re: No 100 HZ timer !
this is one of linux biggest weaknesses. the fixed interval timer is a throwback. it should be replaced with a variable interval timer with interrupts on demand for any system with a cpu sane/modern enough to have an on-chip interrupting decrementer. (i.e just about any modern chip) On Mon, 09 Apr 2001, Jeff Dike wrote: > [EMAIL PROTECTED] said: > > I have a suggestion that might seem unusual at first but it is > > important for Linux on S/390. We are facing the problem that we want > > to start many (> 1000) Linux images on a big S/390 machine. Every > > image has its own 100 HZ timer on every processor the images uses > > (normally 1). On a single image system the processor use of the 100 HZ > > timer is not a big deal but with > 1000 images you need a lot of > > processing power just to execute the 100 HZ timers. You quickly end up > > with 100% CPU only for the timer interrupts of otherwise idle images. > > This is going to be a problem for UML as well, and I was considering something > very similar. I did a quick scan of your prose, and the description sounds > like what I had in mind. > > So, count me in as a supporter of this. > > A small request: Since S/390 is not the only port that needs this, I'd be > happy if it was made as generic as possible (and it may already be, I haven't > gone through the code yet). > > Jeff > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- /*** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: softirq buggy
On Mon, Apr 09, 2001 at 09:48:02PM +0400, [EMAIL PROTECTED] wrote: > Hello! > > > Btw, you don't schedule the ksoftirqd thread if do_softirq() returns > > from the 'if(in_interrupt())' check. > > ksoftirqd will not be switched to before the first schedule > or ret form syscall, when softirqs will be processed in any case. > So, wake up in this case would be mistake. Agreed. > The _real_ problem is softirqs generated from another softirqs: > additonal thread is made _not_ to speed up softirqs, but to _tame_ > them (if I understood Andres's explanations correctly). Exactly. Andrea - 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: goodbye
[EMAIL PROTECTED] wrote: > > Joseph Carter <[EMAIL PROTECTED]> wrote: > > >Let's see, ORBS takes out the ISP route, DUL takes out the direct one. Is > >it any wonder people are hostile toward those two lists? > > Exactly. I hate spam, but I hate ORBS and DUL even more. If I'm going to get > the shaft, I'd rather it be from the "bad guys" (spammers) than from > self-appointed net.cops. > > Wayne > > - > 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/ Amen!!! - 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: goodbye || alternatives
Or you can do as I have and setup port 26 SMTP, thereby routing around nazi ISP created damage. Believe me, the damage that RBL, ORBS, etc can do is incredible. I still use them, but I use them carefully and I provide escape routes for people who are still under a global everybody-is-guilty-by-default umbrella. Any person who is in such a position is free to contact me and arrange for SMTP transit. -d Richard Gooch wrote: > It's not a guilty-by-default attitude. The DUL is a way for ISPs to > say "we can't make users accountable for email sent from these IP's, > so if you're concerned about potential SPAM, block them at your > end. We've set up a relay so our users can still send out email but > can be held accountable for abuses". > > The ISP could have blocked outgoing port 25 instead, forcing you to go > via the relay. Then you'd have no choice. - 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] PS/2 ESDI
All,
Here is a patch I have put together (with much assistance from Jens Axboe)
that permits ps2esdi machines to boot again. It is against 2.4.3. In
case my mailer mangles it, it is also available at the following URL.
http://www.sound.net/~hald/projects/ps2esdi/ps2esdi-2.4.3.patch0
Thanks, and not on the list,
Hal Duston
[EMAIL PROTECTED]
Bring ps2esdi driver up to date with current block device architecture.
Make it boot.
Change nr_sectors to current_nr_sectors.
Remove recursion.
Remove sleep_on.
Add spinlock to ISR and call end_request from there.
--- linux-2.4.3/drivers/block/ps2esdi.c Fri Oct 27 01:35:47 2000
+++ linux-2.4.3-hdd0/drivers/block/ps2esdi.cSat Apr 7 22:47:03 2001
@@ -89,8 +89,6 @@
static void ps2esdi_initial_reset_int_handler(u_int);
static void ps2esdi_geometry_int_handler(u_int);
-static void ps2esdi_continue_request(void);
-
static int ps2esdi_open(struct inode *inode, struct file *file);
static int ps2esdi_release(struct inode *inode, struct file *file);
@@ -469,29 +467,26 @@
DEVICE_NAME,
CURRENT_DEV, MINOR(CURRENT->rq_dev),
CURRENT->cmd, CURRENT->sector,
- CURRENT->nr_sectors, CURRENT->buffer);
+ CURRENT->current_nr_sectors, CURRENT->buffer);
#endif
/* standard macro that ensures that requests are really on the
list + sanity checks. */
INIT_REQUEST;
- if (virt_to_bus(CURRENT->buffer + CURRENT->nr_sectors * 512) > 16 * MB) {
+ if (virt_to_bus(CURRENT->buffer + CURRENT->current_nr_sectors * 512) > 16 *
+MB) {
printk("%s: DMA above 16MB not supported\n", DEVICE_NAME);
end_request(FAIL);
- if (!QUEUE_EMPTY)
- do_ps2esdi_request(q);
- return;
} /* check for above 16Mb dmas */
- if ((CURRENT_DEV < ps2esdi_drives) &&
- (CURRENT->sector + CURRENT->nr_sectors <=
+ else if ((CURRENT_DEV < ps2esdi_drives) &&
+ (CURRENT->sector + CURRENT->current_nr_sectors <=
ps2esdi[MINOR(CURRENT->rq_dev)].nr_sects)) {
#if 0
printk("%s:got request. device : %d minor : %d command : %d sector :
%ld count : %ld\n",
DEVICE_NAME,
- CURRENT_DEV, MINOR(CURRENT->dev),
+ CURRENT_DEV, MINOR(CURRENT->rq_dev),
CURRENT->cmd, CURRENT->sector,
- CURRENT->nr_sectors);
+ CURRENT->current_nr_sectors);
#endif
@@ -500,21 +495,17 @@
#if 0
printk("%s: blocknumber : %d\n", DEVICE_NAME, block);
#endif
- count = CURRENT->nr_sectors;
+ count = CURRENT->current_nr_sectors;
switch (CURRENT->cmd) {
case READ:
ps2esdi_readwrite(READ, CURRENT_DEV, block, count);
- return;
break;
case WRITE:
ps2esdi_readwrite(WRITE, CURRENT_DEV, block, count);
- return;
break;
default:
printk("%s: Unknown command\n", DEVICE_NAME);
end_request(FAIL);
- if (!QUEUE_EMPTY)
- do_ps2esdi_request(q);
break;
} /* handle different commands */
}
@@ -523,8 +514,6 @@
printk("Grrr. error. ps2esdi_drives: %d, %lu %lu\n", ps2esdi_drives,
CURRENT->sector, ps2esdi[MINOR(CURRENT->rq_dev)].nr_sects);
end_request(FAIL);
- if (!QUEUE_EMPTY)
- do_ps2esdi_request(q);
}
} /* main strategy routine */
@@ -570,8 +559,6 @@
u_short cmd_blk[TYPE_1_CMD_BLK_LENGTH];
/* do some relevant arithmatic */
- CURRENT->current_nr_sectors =
- (count < (2 * MAX_16BIT / SECT_SIZE)) ? count : (2 * MAX_16BIT /
SECT_SIZE);
track = block / ps2esdi_info[drive].sect;
head = track % ps2esdi_info[drive].head;
cylinder = track / ps2esdi_info[drive].head;
@@ -590,13 +577,8 @@
/* send the command block to the controller */
if (ps2esdi_out_cmd_blk(cmd_blk)) {
printk("%s: Controller failed\n", DEVICE_NAME);
- if ((++CURRENT->errors) < MAX_RETRIES)
- return do_ps2esdi_request(NULL);
- else {
+ if ((++CURRENT->errors) >= MAX_RETRIES)
end_request(FAIL);
- if (!QUEUE_EMPTY)
- do_ps2esdi_request(NULL);
- }
}
/* check for failure to put out the command block
Re: [PATCH] Re: softirq buggy
Hello! > Btw, you don't schedule the ksoftirqd thread if do_softirq() returns > from the 'if(in_interrupt())' check. ksoftirqd will not be switched to before the first schedule or ret form syscall, when softirqs will be processed in any case. So, wake up in this case would be mistake. > I assume that this is the most common case of delayed softirq > processing: softirqs have the same latency warranty as rt threads, so that this is not a problem at all. The _real_ problem is softirqs generated from another softirqs: additonal thread is made _not_ to speed up softirqs, but to _tame_ them (if I understood Andres's explanations correctly). Alexey - 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: Processes hanging in D state in 2.4.3 - any findings?
"Eloy A. Paris" wrote: > > Hi guys, > > I have seen several messages posted to l-k about people reporting > processes (mozilla most of the time) hanging in the D state in 2.4.3, > but I haven't seen someone posting a possible explanation or solution > to the problem. It's due to problems in the rw_semaphore implementation. These were basically unused for a year, then a couple of weeks ago we started using them, and the problems came to light. > Anyone knows where does the problem lie, or a workaround for the > problem? I hate going through the fsck that happens when umount fails > because processes are in the D state... I put out a patch yesterday which will fix the problem. Discussions are ongoing... - - 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/
vmlinuz won't build with cmd64X.C
I went in to my .config and disabled 640 and 640 enhanced in favor of trying the 64x ide support. I especially liked the fact that from the code it look to have a /proc table similar the the via driver for my onboard controller. Then during compile I can not get the 64x to correctly build itself into the kernel. Actually it build into the kernel but during the final steps the whole build fails becuase of these errors: make[2]: Leaving directory `/usr/src/linux/arch/i386/lib' make[1]: Leaving directory `/usr/src/linux/arch/i386/lib' ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o \ --start-group \ arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \ drivers/block/block.o drivers/char/char.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/parport/driver.o drivers/char/agp/agp.o drivers/char/drm/drm.o drivers/ide/idedriver.o drivers/scsi/scsidrv.o drivers/cdrom/driver.o drivers/sound/sounddrivers.o drivers/pci/driver.o drivers/pnp/pnp.o drivers/video/video.o drivers/usb/usbdrv.o drivers/input/inputdrv.o drivers/acpi/acpi.o \ net/network.o \ /usr/src/linux/arch/i386/lib/lib.a /usr/src/linux/lib/lib.a /usr/src/linux/arch/i386/lib/lib.a \ --end-group \ -o vmlinux drivers/ide/idedriver.o: In function `ide_setup': drivers/ide/idedriver.o(.text.init+0x712): undefined reference to `cmd640_vlb' drivers/ide/idedriver.o: In function `probe_for_hwifs': drivers/ide/idedriver.o(.text.init+0x918): undefined reference to `ide_probe_for_cmd640x' drivers/ide/idedriver.o: In function `pci_init_cmd64x': drivers/ide/idedriver.o(.text.init+0xb2a): undefined reference to `cmd64x_display_info' make: *** [vmlinux] Error 1 I am running 2.4.3-ac3. Thanks for any help, I would really like to be able to try 64x as opposed to 640. Jordan - 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/
Reiser FS doesn't work with 2.4.4-pre1?
After patching from 2.4.3 to 2.4.4-pre1 my reiserfs volumes failed to mount. I checked that reiserfs was included and tried to load the module manualy. This gave this result: lib/modules/2.4.4-pre1/kernel/fs/reiserfs/reiserfs.o: unresolved symbol strstr /lib/modules/2.4.4-pre1/kernel/fs/reiserfs/reiserfs.o: insmod /lib/modules/2.4.4-pre1/kernel/fs/reiserfs/reiserfs.o failed /lib/modules/2.4.4-pre1/kernel/fs/reiserfs/reiserfs.o: insmod reiserfs failed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: softirq buggy
On Mon, Apr 09, 2001 at 05:26:27PM +0200, Manfred Spraul wrote: > The return path to user space checks for pending softirqs. A delay of And it breaks the loop too if new softirq events become pending again in background. > 1/HZ is only possible if the cpu loops in kernel space without returning > to user space - and the functions that can loop check It is also possible when new events are posted and I think it makes sense to scale the softirq load with the scheduler when it is flooding. Theoretically one could move the _whole_ softirq load into the ksoftirqd, but that would increase the latency too much and I think it is better to use it only as a fallback when we have to giveup but we still would like to keep processing the softirq load so we let the scheduler to choose if we still can do that or if we should giveup on the softirq. > Is a full thread really necessary? Just setting 'need_resched' should be > enough, schedule() checks for pending softirqs. If you abuse need_resched then you can starve userspace again, if you are ok to starve userspace indefinitely then it is more efficient to keep looping forever into do_softirq as far as new events are posted in background instead of exiting do_softirq and waiting the scheduler to kickin again. > And do you have a rough idea how often that new thread is scheduled > under load? The scheduling is not as heavy as with tasks, it's a kernel thread so the tlb isn't touched. However yes it will generate some overhead with schedule() compared to just waiting the 1/HZ but letting the scheduler to understand when the softirq should keep running instead of another task is supposed to be a feature. I run a netpipe run with an alpha SMP as receiver with the ksoftirqd patch and then without and the numbers didn't changed at all even if the ksofitrqd was often running (1/2% of the load of the machine). > Btw, you don't schedule the ksoftirqd thread if do_softirq() returns > from the 'if(in_interrupt())' check. That's not necessary and it's intentional, such check will be passed in the last do_softirq executed before returning to userspace or kernel normal context, the reason of such check is only to avoid recursing too much on the stack during nested irqs. > I assume that this is the most common case of delayed softirq > processing: > > ; in process context > spin_lock_bh(); > ; hw interrupt arrives > ; do_softirq returns immediately > spin_unlock_bh(); This is yet another case and it's handled before returning to userspace so the latency should still be pretty small (and there would be no singificant advantage and almost certainly only a performance drop in waking up ksoftirqd from the `do_softirq returns immediatly' line). Andrea ksofitrqd.png
Re: No 100 HZ timer !
[EMAIL PROTECTED] said: > I have a suggestion that might seem unusual at first but it is > important for Linux on S/390. We are facing the problem that we want > to start many (> 1000) Linux images on a big S/390 machine. Every > image has its own 100 HZ timer on every processor the images uses > (normally 1). On a single image system the processor use of the 100 HZ > timer is not a big deal but with > 1000 images you need a lot of > processing power just to execute the 100 HZ timers. You quickly end up > with 100% CPU only for the timer interrupts of otherwise idle images. This is going to be a problem for UML as well, and I was considering something very similar. I did a quick scan of your prose, and the description sounds like what I had in mind. So, count me in as a supporter of this. A small request: Since S/390 is not the only port that needs this, I'd be happy if it was made as generic as possible (and it may already be, I haven't gone through the code yet). Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.3, VMWare, 2 VMs
Petr Vandrovec wrote: > > On 9 Apr 01 at 12:03, Wade Hampton wrote: > > > Is anyone having problems with running more than > As I already answered on VMware newsgroups: Thanks. I didn't see the post on the VMware newsgroup > VMware's 2.0.3 vmmon module uses save_flags() + cli() > in poll() fops, and after this cli() it calls > spin_lock() :-( It is not safest thing to do. > But it should not cause reboot. You should get > > /dev/vmmon: 11 wait for global VM lock XX I had over 2000 of those in /var/log/messages (not counting the "repeated" lines in /var/log/messages). Yep, that's the problem > > and now dead machine with disabled interrupts... Yes, basically a dead machine with NO response to anything > > As all other callers of HostIF_GlobalVMLock() hold > big kernel lock, easiest thing to do is to add > lock_kernel()/unlock_kernel() around LinuxDriver_Poll() > body. > > Removing whole save_flags/cli is for sure much better, > but it is still in my queue (if you are looking into vmmon > driver, then whole poll mess is there to get wakeup on > next jiffy, and not on next + one...). No, I can wait for the a release that fixes this. If you have a patch or test version, send it to me and I'll test it on my development machine For now, I'll just not use 2 VMs until it is fixed. Cheers, -- W. Wade, Hampton <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.4.2] ne.c: Add to bad_clone_list
>From: Jan-Benedict Glaw ([EMAIL PROTECTED]) >Date: Mon Apr 09 2001 - 12:07:16 EDT >This allows me to use some (old and broken) AT/LANTIC boards. Please re-test this patch. Boards based on DP83905 AT/LANTIC chip should never need to be added to the bad clone list. The bad clone list should now be almost read-only, since it's very unlikely that anyone is making new ISA NE2000 and not following the design rules. Donald Becker [EMAIL PROTECTED] Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 - 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: Unresolved symbol in 2.4.4p1, ia32
> From:Jonathan Hudson <[EMAIL PROTECTED]> > X-Newsreader: knews 1.0b.1 > x-no-productlinks: yes > X-Newsgroups: fa.linux.kernel > Content-Type: text/plain; charset=iso-8859-1 > Date:Sat, 07 Apr 2001 21:01:56 GMT > Bytes: 235 > Sender: [EMAIL PROTECTED] > Precedence: bulk > X-Mailing-List: [EMAIL PROTECTED] > > depmod: *** Unresolved symbols in > /lib/modules/2.4.4-pre1/kernel/drivers/ide/ide-cd.o > depmod: strstr > > depmod: *** Unresolved symbols in > /lib/modules/2.4.4-pre1/kernel/drivers/parport/parport.o > depmod: strstr > - > 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/ > > I think strstr (apparently a new function) got left out of i386_ksyms.c: The following appears to have fixed it for me: --- arch/i386/kernel/i386_ksyms.c.~1~ Mon Apr 9 10:54:58 2001 +++ arch/i386/kernel/i386_ksyms.c Mon Apr 9 12:46:45 2001 @@ -97,6 +97,7 @@ EXPORT_SYMBOL_NOVERS(__put_user_2); EXPORT_SYMBOL_NOVERS(__put_user_4); +EXPORT_SYMBOL(strstr); EXPORT_SYMBOL(strtok); EXPORT_SYMBOL(strpbrk); EXPORT_SYMBOL(simple_strtol); -- todd -- ** This footnote confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.3, VMWare, 2 VMs
On 9 Apr 01 at 12:03, Wade Hampton wrote: > Is anyone having problems with running more than > 1 VM on 2.4.3. I have crashed my host O/S several > times when I try to start two VMs. Currently, > I don't have an oops or other info to report, but > I did see a post on the vmware list about 2.4.3 SMP > and VMWARE. As I already answered on VMware newsgroups: VMware's 2.0.3 vmmon module uses save_flags() + cli() in poll() fops, and after this cli() it calls spin_lock() :-( It is not safest thing to do. But it should not cause reboot. You should get /dev/vmmon: 11 wait for global VM lock XX and now dead machine with disabled interrupts... As all other callers of HostIF_GlobalVMLock() hold big kernel lock, easiest thing to do is to add lock_kernel()/unlock_kernel() around LinuxDriver_Poll() body. Removing whole save_flags/cli is for sure much better, but it is still in my queue (if you are looking into vmmon driver, then whole poll mess is there to get wakeup on next jiffy, and not on next + one...). Petr Vandrovec [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Oops in networking with 2.4.3
Hi, I've got a dual CPU (Pentium-Pro), Adaptec 7880 SCSI adapter machine with two 100Mbps ethernet cards (Linksys / Tulip), and a 16/4 Token-ring card (IBM Olympic chipset) in it. The kernel configuration is attached in this email. I installed Debian 2.2r2 and upgraded the prereqs for the 2.4 kernels and compiled 2.4.3 . During the boot process, the machine dies with an oops while loading named. I uninstalled named, which allowed the boot process to complete, but the machine would die again whenever I did a 'ping'. I compiled 2.4.2 . This kernel worked fine. I kept stepping up through the pre-patches until I found that 2.4.3-pre6 is what causes the problem. Given the attached ksymoops-translation attached, I am inclined to believe that the "network driver merge" patch from Jeff Garzik is the culprit - but this amateur will defer to the opinion of the experts. If more info is needed to help debug this problem, please ask. Thanks, Kenneth # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # # CONFIG_EXPERIMENTAL is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set CONFIG_M686=y # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_TOSHIBA is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set # CONFIG_MTRR is not set CONFIG_SMP=y CONFIG_HAVE_DEC_LOCK=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_MISC is not set # CONFIG_PM is not set # CONFIG_APM_IGNORE_USER_SUSPEND is not set # CONFIG_APM_DO_ENABLE is not set # CONFIG_APM_CPU_IDLE is not set # CONFIG_APM_DISPLAY_BLANK is not set # CONFIG_APM_RTC_IS_GMT is not set # CONFIG_APM_ALLOW_INTS is not set # CONFIG_APM_REAL_MODE_POWER_OFF is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Plug and Play configuration # # CONFIG_PNP is not set # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_LOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_RAM is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set CONFIG_NETLINK=y CONFIG_RTNETLINK=y # CONFIG_NETLINK_DEV is not set # CONFIG_NETFILTER is not set # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_RTNETLINK=y CONFIG_NETLINK=y # CONFIG_IP_MULTIPLE_TABLES is not set # CONFIG_IP_ROUTE_MULTIPATH is not set # CONFIG_IP_ROUTE_TOS is not set CONFIG_IP_ROUTE_VERBOSE=y # CONFIG_IP_ROUTE_LARGE_TABLES is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # # # # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Telephony Support # # CONFIG_PHONE is not set # # ATA/IDE/MFM/RLL support # CONFIG_IDE=y # # IDE, ATA and ATAPI Block devices # CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_HD_IDE is not set # CONFIG_BLK_DEV_HD is not set CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set # CONFIG_BLK_DEV_IDEDISK_VENDOR is not set #
[PATCH 2.4.2] ne.c: Add to bad_clone_list
Hi!
This allows me to use some (old and broken) AT/LANTIC boards.
MfG, JBG
--
Fehler eingestehen, Größe zeigen: Nehmt die Rechtschreibreform zurück!!!
/* Jan-Benedict Glaw <[EMAIL PROTECTED]> -- +49-172-7608481 */
keyID=0x8399E1BB fingerprint=250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB
"insmod vi.o and there we go..." (Alexander Viro on linux-kernel)
--- drivers/net/ne.c.orig Mon Apr 9 18:01:01 2001
+++ drivers/net/ne.cMon Apr 9 18:03:37 2001
@@ -101,6 +101,7 @@
{"PCM-4823", "PCM-4823", {0x00, 0xc0, 0x6c}}, /* Broken Advantech MoBo */
{"REALTEK", "RTL8019", {0x00, 0x00, 0xe8}}, /* no-name with Realtek chip */
{"LCS-8834", "LCS-8836", {0x04, 0x04, 0x37}}, /* ShinyNet (SET) */
+{"AT/Lan.", "AT/Lantic", {0x08, 0x00, 0x06}}, /* Broken DP83905 clone */
{0,}
};
#endif
PGP signature
2.4.3, VMWare, 2 VMs
Greetings, Is anyone having problems with running more than 1 VM on 2.4.3. I have crashed my host O/S several times when I try to start two VMs. Currently, I don't have an oops or other info to report, but I did see a post on the vmware list about 2.4.3 SMP and VMWARE. Host: dual PIII/800, 256 M RAM, RedHat 6.2 with updates, 2.4.3 VM1: RedHat 7.0 with recent updates VM2: RedHat 7.0 with 2.4.3 and LIDS Cheers, -- W. Wade, Hampton <[EMAIL PROTECTED]> If Microsoft Built Cars: Every time they repainted the lines on the road, you'd have to buy a new car. Occasionally your car would just die for no reason, and you'd have to restart it, but you'd just accept this. - 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: tulip (was RE: Kernel 2.4.3 fails to compile)
Jeff Garzik said: [snip conversation about NETDEV WATCHDOG errors on ADMTek Comet tulip clone card] > > Ok, this should be fixed in the latest patches sent to Alan and Linus. Testing with 2.4.3-ac3 and so far, so good. Thanks! -- Manuel A. McLure - Unify Corp. Technical Support <[EMAIL PROTECTED]> Space Ghost: "Hey, what happened to the-?" Moltar: "It's out." SG: "What about-?" M: "It's fixed." SG: "Eh, good. Good." - 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/
skb allocation problems
hello all,
For the past week, i am having problems with (possibly BUGGY) memory
allocation by the kernel in my NAT-PT module. I posted this to netdev before
but did not get any response. So, here i am with some more proof:)
In my IPV6-IPV4 translator module, i capture an IPV4 packet by registering
at the netfilter pre-routing hook, i translate it to an IPV6 packet and
allocate a new skb for the translated packet and put the packet back in the
IPV6 stack...but when i allocate the skb for the translated packet, i start
getting the problems. A call to alloc_skb gives me the memory area that is
already being pointed by the IPV4 packet which came into the hook...
I have written a test module which closely mirrors what my code tries to
do(attached below). This is what i get:
PRE_R: old skb:c371ee40 new skb:c371ee30
<7>NAT: 3 dropping untracked packet c350fa00 1 192.168.102.22 ->
192.168.102.29
The above message was generated by sending a udp packet from a simple udp
client on the host 192.168.102.29 to 192.168.102.22. The test module was on
the host 192.168.102.22.
As you can see the memory allocated to new skb is already being pointed to
by the packet that came in (old skb). Isn't that strange/BUGGY ??
And regarding the netfilter message, the packet that is being dropped by
netfilter is an ICMP protocol unreachable message since there is no udp
server listening on 192.168.102.29. Why conntrack drops the icmp error
packet is a question for the netfilter guys:)
I have been fighting this bug or whatever it is for a week now and i can't
get anywhere. And i cannot produce this behaviour reliably i.e. this test
module allocates different memory area most of the time & seems to work fine
but when it goes bad, it keeps on allocating the same overlapping
addresses...and never stops misbehaving until i reboot the machine
Any help would be appreciated.
PS: I am not on the linux-kernel mailing list & yes, i use the 2.4.1 kernel.
TIA,
imran
-
#define __KERNEL__
#define MODULE
#include
#include
#include
static unsigned int
prehook(unsigned int hook, struct sk_buff **pskb,
const struct net_device *indev,
const struct net_device *outdev,
int (*okfn)(struct sk_buff *)){
struct sk_buff *skb;
printk("\nPRE_R: old skb:%p", (*pskb)->data);
/* translation happens in the real code here */
skb = alloc_skb((*pskb)->len, GFP_ATOMIC);
if(!skb)
printk("alloc failed");
skb_reserve(skb, 16);
printk(" new skb:%p", skb->data);
kfree_skb(skb);
/*actually it is something like this in my real code:
kfree(*pskb);
return NF_STOLEN;
*/
return NF_ACCEPT;
}
static struct nf_hook_ops pre =
{
{NULL, NULL}, /* link list */
prehook,/* the hook fn */
PF_INET, /* protocol family */
NF_IP_PRE_ROUTING,/* hook no*/
NF_IP_PRI_CONNTRACK/* priority */
};
static int init_module(void) {
nf_register_hook();
}
static void cleanup_module(void) {
nf_unregister_hook();
}
-
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/
OPPS with 2.4.3 and LIDS
See attached oops description. -- W. Wade, Hampton <[EMAIL PROTECTED]> BUG report for vmguest5 on Mon Apr 9 07:00:32 EDT 2001 [1.] One line summary of the problem: Kernel oops with 2.4.3+LIDS running under VMWare [2.] Full description of the problem/report: The machine that crashed is a RedHat 7.0 virtual host running under VMWare 2.0.3 on a RedHat 6.2 base host. The virtual host has 2.4.3 with LIDS 1.0.7. This report is on the virtual host that includes LIDS. Over the weekend, I had two VMs running on my Linux box (RH 6.2 with 2.4.3), but apparently there is an issue with vmware and 2.4.3 SMP. The box locked up (base O/S). Note, 2.4.3 seems much better than 2.4.1 for vmware lockups with 2 VMs, but still I don't recommend it, yet. This is a separate issue and I have yet to get an oops I can report. This will be a separate report This morning, I rebooted the base O/S, then once it was up and functioning properly, I started the test VM with LIDS. The test VM started booting, then came to the login prompt. It then started running slocate, etc. A few minutes after booting, I got the OOPS. [3.] Keywords (i.e., modules, networking, kernel): kernel 2.4.3, VMWare, LIDS [4.] Kernel version (from /proc/version): Linux version 2.4.3 (root@vmguest5) (gcc version 2.96 2731 (Red Hat Linux 7.0)) #3 Fri Apr 6 10:40:10 EDT 2001 [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) Trace; c012dc3b Trace; c01fccf5 Trace; c01fcbb0 Trace; c011a0c3 Trace; c01163fc Trace; c0116306 Trace; c011620b Trace; c01083af Trace; c0106fd0 Original OOPS: LIDS: slocate (3 5 inode 96962) pid 1220 ppid 1218 user (0/0) on NULL tty: voliated CAP_DAC_READ_SEARCH kernelb BUG at slab.c:1073! invalid operand: CPU:0 EIP:0010:[c012d99b>] EFLAGS: 0286 ... Process sendmail (pid: 1552, stackpage c397b000) Stack: c0219f9e c021a03e 0431 00030002 c159bbfc c1134050 c25b5005 0026c8ca 0003 0015 c1117570 0007 c1263d20 c012dc3b c1117570 0007 0282 0001 c111b260 1000 c22089e0 000c c01fccf5 Call Trace: [] [] [] [] [] [] [] [] [] Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing [6.] A small shell script or example program which triggers the problem (if possible) none [7.] Environment [7.1.] Software (add the output of the ver_linux script here) If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Base O/S: - RedHat 6.2 (VA) with updates - Kernel 2.4.3 - VMWare 2.0.3 VMHost O/S (the one that crashed): - RedHat 7.0 with updates - Kernel 2.4.3 - part of pcnet32 patch removed to get it to work (previous kernel msgs) - LIDS 1.0.7 patch Linux vmguest5 2.4.3 #3 Fri Apr 6 10:40:10 EDT 2001 i686 unknown Gnu C 2.96 Gnu make 3.79.1 binutils 2.10.0.18 util-linux 2.10m modutils 2.3.21 e2fsprogs 1.18 pcmcia-cs 3.1.19 Linux C Library> libc.2.2 Dynamic linker (ldd) 2.2 Procps 2.0.7 Net-tools 1.56 Console-tools 0.3.3 Sh-utils 2.0 Modules Loaded pcnet32 sb sb_lib uart401 sound soundcore [7.2.] Processor information (from /proc/cpuinfo): Base O/S: - Dual PIII/800 VMHost O/S (the one that crashed): processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 3 cpu MHz : 931.349 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1228.80 [7.3.] Module information (from /proc/modules): pcnet3211600 1 (autoclean) sb 7520 0 (unused) sb_lib 34528 0 [sb] uart401 6416 0 [sb_lib] sound 58864 0 [sb_lib uart401] soundcore 4080 5 [sb_lib sound] [7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem) -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 0220-022f : soundblaster 02e8-02ef : serial(auto) 02f8-02ff : serial(auto) 0330-0333 : MPU-401 UART 0376-0376 : ide1 03c0-03df : vga+ 03e8-03ef : serial(auto) 03f6-03f6 : ide0 03f8-03ff : serial(auto) 0cf8-0cff : PCI conf1 1000-101f : Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] 1000-101f : PCnet/PCI II 79C970A 1020-103f : Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (#2) 1020-103f :
oops script for /usr/src/linux/scripts
I made a simple bug_report.sh script to facilitate generating a bug report. It could be included in /usr/src/linux/scripts and could be referenced in /usr/src/linux/BUG-REPORTING. If anyone is interested, please see attached. Cheers, -- W. Wade, Hampton <[EMAIL PROTECTED]> bug_report.sh
