Re: VIA audio and parport in 2.4.2
On Fri, 16 Mar 2001, Will Newton wrote: > On Fri, 16 Mar 2001, Tim Waugh wrote: > > > > I don't know why it prints it twice. > > > > Looks like the module is getting loaded, then unloaded, then loaded > > again. Perhaps because of module autocleaning? > > Could be, but the final lp0 line is only printed once: > lp0: using parport0 (interrupt-driven). > > > > I also get spurios interrupts on 7 when the parport is not loaded. > > > > I'm not sure what you mean here. Can you be more specific? > > messages.1:Mar 8 22:49:00 dogfox kernel: spurious 8259A interrupt: IRQ7. I see these once in a while too in 2.4.x, and only when copying largish files between boxes. NIC is IRQ-10, but the spurious interrupt is always IRQ-7. I'm not using the printer port for anything on this box. It only happens here when the network is going full bore for at least a few secs. -Mike - 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/
measurement
Hello,
I use PSCHED_GET_TIME(stamp) to measure the
delay of some kernel function.
function_name( ) {
int psched_clock_scale;
psched_time_t stamp1, stamp2;
psched_tdiff_t delay;
PSCHED_GET_TIME(stamp1);
PSCHED_GET_TIME(stamp2);
delay=PSCHED_TDIFF(stamp2, stamp1);
printk(KERN_INFO "[%ld], [%ld], [%ld]\n", stamp1, stamp2, delay);
}
But the result like this [135967], [0], [135967].
I really don't know why stamp2 is 0, and
I can't find out the scale of stamp1/stamp2.
(micro-second ?? )
Thanks.
Cheers,
Steven
-
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/
Potential free/use-after-free bugs
Hello,
I am another student of Dawson Engler's working on the meta-level
compilation project. I have just finished processing the results of a
checker which looks for double frees and use-after-frees. I think we have
found 12-14 bugs. I also have some questions regarding skbs. Our checker
found a lot of instances where the skb is freed, then its length field is
accessed. I have included an example location below. Is this a bug or
not? It appears that the length field is not cleared as the skbs are
referenced counted and the state clearing leaves the length alone. I am
unsure as to whether this is a bug, bad practice, or just fine, though.
Any help would be appreciated. Thanks.
Seth Hallem
==
[BUG] Returns a freed pointer. Probably bad but I'm not sure.
/home/shallem/oses/linux/2.4.1/fs/proc/generic.c:438:proc_symlink:
ERROR:FREE:430:438: WARN: Use-after-free of "ent"! set by 'kfree':430
Start --->
kfree(ent);
goto out;
}
out:
Error --->
return ent;
}
[BUG] Potential double or more free.
/home/shallem/oses/linux/2.4.1/drivers/usb/serial/belkin_sa.c:236:belkin_sa_shutdown:
ERROR:FREE:237:236: Use-after-free of 'private'! set by 'kfree':237
}
/* My special items, the standard routines free my urbs */
if (serial->port->private)
Error --->
Start --->
kfree(serial->port->private);
}
[BUG] Copy paste of above potential bug.
/home/shallem/oses/linux/2.4.1/drivers/usb/serial/mct_u232.c:277:mct_u232_shutdown:
ERROR:FREE:278:277: Use-after-free of 'private'! set by 'kfree':278
[BUG]
/home/shallem/oses/linux/2.4.1/drivers/sound/sound_core.c:178:sound_insert_unit:
ERROR:FREE:171:178: Use-after-free of 's'! set by 'kfree':171
if(r<0)
Start --->
kfree(s);
if (r == low)
sprintf (name_buf, "%s", name);
else
sprintf (name_buf, "%s%d", name, (r - low) / SOUND_STEP);
s->de = devfs_register (devfs_handle, name_buf,
DEVFS_FL_NONE, SOUND_MAJOR, s->unit_minor,
Error --->
S_IFCHR | mode, fops, NULL);
return r;
[BUG] Might be okay, but probably not a good idea. Seems to put scb on
the free list, then derefs it in the call to ips_send_cmd. Okay if this
is not interruptible?
/home/shallem/oses/linux/2.4.1/drivers/scsi/ips.c:2839:ips_next:
ERROR:FREE:2818:2839: WARN: Use-after-free of "scb"! set by
'ips_freescb':2818
Start --->
ips_freescb(ha, scb);
break;
case IPS_SUCCESS_IMM:
if (scb->scsi_cmd) {
... DELETED lines ...
IPS_QUEUE_LOCK(&ha->copp_waitlist);
continue;
}
Error --->
ret = ips_send_cmd(ha, scb);
if (ret == IPS_SUCCESS) {
[BUG] same as above.
/home/shallem/oses/linux/2.4.1/drivers/scsi/ips.c:2839:ips_next:
ERROR:FREE:2827:2839: WARN: Use-after-free of "scb"! set by
'ips_freescb':2827
[BUG] lapbeth_prev is dereferenced on the next iteration through the loop.
/home/shallem/oses/linux/2.4.1/drivers/net/wan/lapbether.c:116:lapbeth_check_devices:
ERROR:FREE:113:116: WARN: Use-after-free of "lapbeth"! set by 'kfree':113
Start --->
kfree(lapbeth);
}
Error --->
lapbeth_prev = lapbeth;
}
[BUG] bpq is freed, assigned to another variable (bpq_prev), then
dereferenced on the next time through the loop. Analogous to above case
with lapbeth_prev.
/home/shallem/oses/linux/2.4.1/drivers/net/hamradio/bpqether.c:196:bpq_check_devices:
ERROR:FREE:193:196: WARN: Use-after-free of "bpq"! set by 'kfree':193
[BUG] Derefs dev on next iteration unless dev is set to NULL.
/home/shallem/oses/linux/2.4.1/drivers/net/sundance.c:1233:sundance_remove1:
ERROR:FREE:1243:1233: Use-after-free of 'dev'! set by 'kfree':1243
Error --->
while (dev) {
struct netdev_private *np = (void *)(dev->priv);
unregister_netdev(dev);
#ifdef USE_IO_OPS
release_region(dev->base_addr,
pci_id_tbl[np->chip_id].io_size);
#else
release_mem_region(pci_resource_start(pdev, 1),
pci_id_tbl[np->chip_id].io_size);
iounmap((char *)(dev->base_addr));
#endif
Start --->
kfree(dev);
}
[BUG]
/home/shallem/oses/linux/2.4.1/drivers/net/rcpci45.c:1265:RC_allocate_and_post_buffers:
ERROR:FREE:1264:1265: Use-after-free of 'p'! set by 'kfree':1264
Start --->
kfree(p);
Error --->
return(p[0]);/* return the number of posted buffers */
}
[BUG]
/home/shallem/oses/linux/2.4.1/drivers/net/irda/nsc-ircc.c:319:nsc_ircc_open:
ERROR:FREE:318:319: Use-after-free of 'self'! set by 'kfree':318
Start --->
kfree(self);
Error --->
kfree(self->rx_buff.head);
[CHECKER] 28 potential interrupt errors
Hi,
Here are yet more results from the MC project. This checker looks for
inconsistent usage of interrupt functions. For example, it notices when
interrupts can be either on or off when a function exits. It tracks
cli(), sti(), save_flags() and so forth. We've hand-inspected the results
to ensure that the ones you see here are likely to be errors.
As usual, please CC us at [EMAIL PROTECTED] if you can verify these
potential errors or show that these bugs are false positives.
Important: The code snippets with each bug here were automatically culled
from the source, not manually selected, so they are sometimes inaccurate
as to the actual location of the bug. We've included a comment before
each bug to help in understanding what the checker found, but the only way
to know for sure is to inspect the source.
-Junfeng & Andy
Where the errors are:
+--++
| file | fn |
+--++
| drivers/cdrom/cm206.c| receive_byte |
| drivers/cdrom/cm206.c| send_command |
| drivers/char/ip2/i2lib.c | i2QueueCommands|
| drivers/char/n_r3964.c | add_msg|
| drivers/char/rio/rioroute.c | RIOFixPhbs |
| drivers/char/rio/riotable.c | RIODeleteRta |
| drivers/i2o/i2o_block.c | i2ob_del_device|
| drivers/ide/ide.c| ide_spin_wait_hwgroup |
| drivers/isdn/hisax/config.c | checkcard |
| drivers/isdn/hisax/isar.c| isar_load_firmware |
| drivers/isdn/isdn_ppp.c | isdn_ppp_bind |
| drivers/net/appletalk/cops.c | cops_rx|
| drivers/net/hamradio/soundmodem/sm_wss.c | wss_set_codec_fmt |
| drivers/net/irda/irport.c| irport_net_ioctl |
| drivers/net/irda/irtty.c | irtty_net_ioctl|
| drivers/net/irda/nsc-ircc.c | nsc_ircc_net_ioctl |
| drivers/net/irda/toshoboe.c | toshoboe_net_ioctl |
| drivers/net/irda/w83977af_ir.c | w83977af_net_ioctl |
| drivers/net/pcmcia/wavelan_cs.c | wavelan_get_wireless_stats |
| drivers/net/tokenring/smctr.c| smctr_open_tr |
| drivers/net/wan/comx-hw-mixcom.c | MIXCOM_open|
| drivers/net/wan/lmc/lmc_main.c | lmc_watchdog |
| drivers/scsi/eata_dma.c | eata_queue |
| drivers/scsi/qla1280.c | qla1280_intr_handler |
| drivers/sound/ad1848.c | ad1848_resume |
| drivers/sound/emu10k1/midi.c | emu10k1_midi_callback |
| drivers/sound/sscape.c | sscape_pnp_upload_file |
| net/irda/irttp.c | irttp_proc_read|
+--++
Listing:
[BUG] sleep_or_timeout will call interruptible_sleep_on, which will save disabled
flags and then restore them.
/u2/acc/oses/linux/2.4.1/drivers/cdrom/cm206.c:474:send_command: ERROR:INTR:462:474:
Interrupts inconsistent, severity `20':474
if (!(inw(r_line_status) & ls_transmitter_buffer_empty)) {
cd->command = command;
Start --->
cli(); /* don't interrupt before sleep */
outw(dc_mask_sync_error | dc_no_stop_on_error |
(inw(r_data_status) & 0x7f), r_data_control);
/* interrupt routine sends command */
Save & Restore
flags here --->
if (sleep_or_timeout(&cd->uart, UART_TIMEOUT)) {
debug(("Time out on write-buffer\n"));
stats(write_timeout);
... DELETED 2 lines ...
}
debug(("Write commmand delayed\n"));
}
else outw(command, r_uart_transmit);
Error --->
}
uch receive_byte(int timeout)
{
uch ret;
-
[BUG] sleep_or_timeout will call interruptible_sleep_on, which will save disabled
flags and then restore them.
/u2/acc/oses/linux/2.4.1/drivers/cdrom/cm206.c:499:receive_byte: ERROR:INTR:479:494:
Interrupts inconsistent, severity `30':494
{
uch ret;
Start --->
cli();
debug(("cli\n"));
ret = cd->ur[cd->ur_r];
if (cd->ur_r != cd->ur_w) {
sti();
debug(("returning #%d: 0x%x\n", cd->ur_r, cd->ur[cd->ur_r]));
cd->ur_r++; cd->ur_r %= UR_SIZE;
... DELETED 5 lines ...
#ifdef STATISTICS
if (timeout==UART_TIMEOUT) stats(receive_timeout) /* no `;'! */
else stats(dsb_timeout);
#endif
Error --->
return 0xda;
}
ret = cd->ur[cd->ur_r];
debug(("slept; returning #%d: 0x%x\n", cd->ur_r, cd->ur[cd->ur_r]));
cd->ur_r++; cd->ur_r %= UR_SIZE;
-
Re: parport not detected
Yup! nano kernel: parport0: PC-style at 0x378, irq 7 [SPP,PS2,EPP] nano kernel: parport0: Printer, Hewlett-Packard HP LaserJet 6L I setup everything as you describe below. I don't remember having to do all this stuff before(on other machines anyway). I guess I'm used to RH's fluffed-up stock kernels. Thanks, Mike On Fri, Mar 16, 2001 at 06:00:07PM -0800, Tim Moore wrote: > > The parallel port is not being detected on my ABIT KT7A KT133 w/ Athlon > > Also try comp.os.linux.hardware. > > BIOS > > 278/irq5 > 378/irq7 > EPP 1.9 > > .config > --- > CONFIG_PARPORT=y > CONFIG_PARPORT_PC=y > CONFIG_PNP=y > CONFIG_PNP_PARPORT=y > CONFIG_PRINTER=y > CONFIG_PRINTER_READBACK=y > > kernal boot params > -- > append="parport=0x378,7 parport=0x278,5" > > options for /etc/rc.d/rc.local > -- > # abort on error, careful error check, trust IRQ. > # see tunelp(8) & /usr/src/linux/drivers/misc/lp.c > > /usr/sbin/tunelp /dev/lp0 -a on -o on -T on > /usr/sbin/tunelp /dev/lp1 -a on -o on -T on > > looks like this (lp1 was powered down at boot time) > > Feb 25 02:57:39 dell kernel: parport0: PC-style at 0x378, irq 7 > [SPP,PS2,EPP] > Feb 25 02:57:39 dell kernel: parport0: Printer, Hewlett-Packard HP > LaserJet 1100 > Feb 25 02:57:39 dell kernel: parport1: PC-style at 0x278, irq 5 > [SPP,PS2,EPP] > Feb 25 02:57:39 dell kernel: parport1: no IEEE-1284 device present. > Feb 25 02:57:40 dell kernel: lp0: using parport0 (interrupt-driven). > Feb 25 02:57:40 dell kernel: lp1: using parport1 (interrupt-driven). > > > -- - 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/
[CHECKER] 16 potential locking bugs in 2.4.1
Here are some more results from the MC project. These are 16 errors found
in 2.4.1 related to inconsistent use of locks. As usual, if you can
verify any of these or show that they are false positives, please let us
know by CC'ing [EMAIL PROTECTED]
-Andy Chou
PS. I noticed that many of the locking errors I sent out previously for
2.3.99-pre6 were fixed. Others remain still, and some of these may have
been reported earlier.
Where the bugs are:
+-++
| file| fn |
+-++
| drivers/char/cyclades.c | cyy_interrupt |
| drivers/i2o/i2o_block.c | i2ob_del_device|
| drivers/media/video/saa7110.c | saa7110_write_block|
| drivers/mtd/cfi_cmdset_0001.c | cfi_intelext_suspend |
| drivers/mtd/cfi_cmdset_0002.c | cfi_amdext_suspend |
| drivers/net/de4x5.c | de4x5_interrupt|
| drivers/net/pcmcia/wavelan_cs.c | wavelan_get_wireless_stats |
| drivers/net/sk98lin/skge.c | SkGeChangeMtu |
| drivers/net/wan/lmc/lmc_main.c | lmc_ioctl |
| drivers/net/wan/lmc/lmc_main.c | lmc_watchdog |
| drivers/scsi/qla1280.c | qla1280_intr_handler |
| drivers/sound/cmpci.c | cm_midi_release|
| drivers/sound/trident.c | trident_release|
| fs/coda/psdev.c | coda_psdev_open|
| fs/nfsd/vfs.c | nfsd_link |
| fs/nfsd/vfs.c | nfsd_symlink |
+-++
Listing:
-
[BUG]
/u2/acc/oses/linux/2.3.99-pre6/drivers/net/sk98lin/skge.c:2511:SkGeChangeMtu:
ERROR:LOCK:2418:2511: Inconsistent
lock using `spin_lock':2418
Flags variable re-used.
static int SkGeChangeMtu(struct net_device *dev, int NewMtu)
{
...
--> Use "Flags"
spin_lock_irqsave(&pAC->SlowPathLock, Flags);
SkEventQueue(pAC, SKGE_RLMT, SK_RLMT_STOP, EvPara);
SkEventDispatcher(pAC, pAC->IoBase);
for (i=0; iGIni.GIMacsFound; i++) {
--> Re-use of "Flags"
spin_lock_irqsave(
&pAC->TxPort[i][TX_PRIO_LOW].TxDesRingLock,
Flags);
}
...
for (i=pAC->GIni.GIMacsFound-1; i>=0; i--) {
--> Restore bogus "Flags"
spin_unlock_irqrestore(
&pAC->TxPort[i][TX_PRIO_LOW].TxDesRingLock,
Flags);
}
--> Restore bogus "Flags" again
spin_unlock_irqrestore(&pAC->SlowPathLock, Flags);
return 0;
} /* SkGeChangeMtu */
-
[BUG] error condition
/u2/acc/oses/linux/2.4.1/drivers/i2o/i2o_block.c:1496:i2ob_del_device:
ERROR:LOCK:1416:1496: Inconsistent
lock using `spin_lock':1416
void i2ob_del_device(struct i2o_controller *c, struct i2o_device *d)
{
--> Lock
spin_lock_irqsave(&io_request_lock, flags);
...
if(unit >= MAX_I2OB<<4)
{
printk(KERN_ERR "i2ob_del_device called, but not in dev
table!\n");
--> Forgot to unlock
return;
}
...
}
-
[BUG] GEM continue statement causes potential double lock
/u2/acc/oses/linux/2.4.1/drivers/char/cyclades.c:1174:cyy_interrupt:
ERROR:LOCK:1174:1174: Double
lock using `spin_lock':1174
static void
cyy_interrupt(int irq, void *dev_id, struct pt_regs *regs)
{
do{
had_work = 0;
for ( chip = 0 ; chip < cinfo->num_chips ; chip ++) {
...
while ( (status = cy_readb(base_addr+(CySVRR< Lock
spin_lock(&cinfo->card_lock);
...
if(info->tty == 0){
...
}else{ /* there is an open port for this data */
...
if ( j == CyIVRRxEx ) { /* exception */
...
if(data & info->ignore_status_mask){
info->icount.rx++;
--> May cause double lock?
continue;
}
if (tty->flip.count < TTY_FLIPBUF_SIZE){
-
[BUG] forgot to unlock
/u2/acc/oses/linux/2.4.1/drivers/media/video/saa7110.c:92:saa7110_write_block:
ERROR:LOCK:79:92: Inconsistent
lock using `spin_lock':79
static
int saa7110_write_block(struct saa7110* decoder, unsigned const char
*data, unsigned int len)
{
--> Lock
LOCK_I2C_BUS(decoder->bus);
i2c_start(decoder->bus);
i2c_sendbyte(decoder->bus,decoder->addr,I2C_
oops in 2.4.2-ac20
What the subject says. I copied the oops by hand, but the output of ksymoops doesn't seem too totally wrong, so I guess I didn't botch it :) I can't blame the box; I was about to Aiee myself, radeonfb is so slow. ksymoops output: ---8< ksymoops 2.3.7 on i686 2.4.2-ac20. Options used -V (default) -k /var/log/ksymoops/20010317003908.ksyms (specified) -l /var/log/ksymoops/20010317003908.modules (specified) -O (specified) -M (specified) Kernel BUG at printk.c:458! invalid operand: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010286 eax: 001c ebx: ce27090c ecx: c02a97c0 edx: 4dee esi: cda3b000 edi: cda3b16f ebp: esp: c0dc7e34 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c02c7000) Stack: c0255934 01ca c01a0a10 cda3b000 c0194caf cda3b000 0003 cda3b000 0001 cda3b56c c02ae800 42000246 c01adacf a000 cda3b56f cda3b16f c0344260 c01b2e55 c03442a0 c01b2770 03e8 c01b2cb8 0002 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 08 b9 c0 97 2a c0 f0 ff 0d c0 97 2a c0 0f 88 a1 >>EIP; c011839c<= Trace; c01a0a10 Trace; c0194caf Trace; c01adacf Trace; c01b4e55 Trace; c01b2770 Trace; c01b2cb8 Trace; c0113c0b Trace; c01a64e2 Trace; c01924a7 Trace; c011d299 <__run_task_queue+cd/278> Trace; c011ff5e Trace; c011d0a5 Trace; c011cf85 Trace; c011cdac Trace; c010affa Trace; c01071e0 Trace; c01071e0 Trace; c010962c <__read_lock_failed+1440/2804> Trace; c01071e0 Trace; c01071e0 Trace; c0100018 Before first symbol Trace; c010720d Trace; c0107272 Trace; c0105000 Trace; c01001cf Before first symbol Code; c011839c <_EIP>: Code; c011839c<= 0: 0f 0b ud2a <= Code; c011839e 2: 83 c4 08 add$0x8,%esp Code; c01183a1 5: b9 c0 97 2a c0mov$0xc02a97c0,%ecx Code; c01183a6 a: f0 ff 0d c0 97 2a c0 lock decl 0xc02a97c0 Code; c01183ad 11: 0f 88 a1 00 00 00 js b8 <_EIP+0xb8> c0118454 <0>Kernel panic: Aiee, killing interrupt handler! >8--- output of ver_linux: ---8< util-linux util-linux Note: /usr/bin/fdformat is obsolete and is no longer available. util-linux Please use /usr/bin/superformat instead (make sure you have the util-linux fdutils package installed first). Also, there had been some util-linux major changes from version 4.x. Please refer to the documentation. util-linux modutils 2.4.2 e2fsprogs 1.19 reiserfsprogs 3.x.0b PPP2.4.0 Linux C Library2.2.2 Dynamic linker (ldd) 2.2.2 Procps 2.0.7 Net-tools 1.58 Kbd1.04 Sh-utils 2.0.11 Modules Loaded ppp_deflate bsd_comp ppp_async ppp_generic slhc >8--- (I guess ver_linux needs updating) /proc/cpuinfo: ---8< processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 3 cpu MHz : 701.611 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: 1399.19 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 3 cpu MHz : 701.611 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 3 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1402.47 >8--- /var/log/ksymoops/20010317003908.modules ---8< agpgart14912 0 (unused) >8--- Anything else? -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: need help: my first packet to my provider gets lost :-( sel: dont send the first one, start with #2 1 1.bak 24.m3u 2cooltek_order.html 3Daccelx_V2-2.0ALPHA-30.i386.rpm 9skin.zip AYB AYB.tar.gz AYB.tar.gz~ Hobby Mail Media MyPilot Nautilus News PC_Product_Compare.pdf Sent Untitled1.bak XF86Config-4 bday_2001.abw bin chesterfield-lemonology-cdart.zip component.reg conni.zip conni_elektra.zip d3_ref.pdf dmusic-158.rmp drag_and_drop2.jpg easymouse+.exe evolution fba06a.pdf fba09a.pdf fba12g.pdf gears.strace index.html kernelnewbies-fortunes.tar.gz linuxq3a-1.27g-beta1.tar.gz lotr_640_internet.mpg lpg-0.4_IPC.ps lpg-0.4_IPC_even.ps mandy.zip mslugx.zip mudsh nezmouse+.exe openlogo-nd.xcf openlogo.xcf
Re: [CHECKER] big stack variables
[EMAIL PROTECTED] said: > ObUML: something fishy happens in UML with multiple exec() in PID 1. > Try to say "telinit u" (or just boot with init=/bin/sh and say exec / > sbin/init) and you've got a nice panic()... ObFix: This is fixed in my current CVS. If you're not so desperate for the fix, then it will be in my 2.4.3 release. Basically, the problem was that it assumed that the only exec done by pid 1 was the kernel thread execing init, and things got exciting when that turned out not to be true. 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: [PATCH] Improved version reporting
Andries.Brouwer writes: >> From: "Albert D. Cahalan" <[EMAIL PROTECTED]> >>> On Wed, 14 Mar 2001 [EMAIL PROTECTED] wrote: > +o Console Tools # 0.3.3# loadkeys -V > +o Mount # 2.10e# mount --version Concerning mount: (i) the version mentioned is too old, >> >> Exactly why? Mere missing features don't make for a required >> upgrade. Version number inflation should be resisted. ... > These days you can mount several filesystems at the same mount point. > The old mount does not understand this at all. > Recent versions of mount act better in this respect, > even though it is still easy to confuse them. The rule should be like this: List the lowest version number required to get 2.2.xx-level features while running a 2.4.xx kernel. Remember what the purpose of the table is. It is a list of REQUIRED upgrades. Failure to upgrade should result in a broken system. So pppd must be listed, since somebody changed the kernel API for 2.4.1. If I run the mount command from Red Hat 6.2, using it as intended for a 2.2.xx kernel, doesn't everything work? There won't be any multi-mount confusion because 2.2.xx can't do that anyway. There isn't any problem with NFSv3 either, since 2.2.xx lacks NFSv3. Basically I ask: would existing scripts for a 2.2.xx kernel break? If the old mount can still do what it used to do, then "mount" need not be listed at all. - 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: scsi_scan problem.
Patrick Mansfield wrote: > > If your testing Doug's patch, it might be a good idea to run with/without > your adapter built as a module, as the kernel is inconsistent in its setting > of "online" in scsi.c: it sets online TRUE after an attach in > scsi_register_device_module(), but leaves online as is after an > attach in scsi_register_host(). > > So, if the scan_scsis set online FALSE, it sometimes is set back to TRUE; > otherwise, I don't think any other code will set online to TRUE (once it > is set to FALSE after its scanned, no one can even open the device, not even sg). > > The online = TRUE should probably be removed from scsi_register_device_module(), > as disks with peripheral qualifier 1 (like Doug's the Clariion storage) > ususally complain when sent a READ CAPACITY. I got such errors when running with > a Clariion DASS (DGC RAID/DISK, scsi attached disk array). In my first post everything but the aic7xxx_old driver was builtin. With it built into the kernel the output is as follows: SCSI subsystem driver Revision: 1.00 (scsi0) found at PCI 0/14/1 (scsi0) Wide Channel B, SCSI ID=7, 32/255 SCBs (scsi0) Downloading sequencer code... 383 instructions downloaded (scsi1) found at PCI 0/14/0 (scsi1) Wide Channel A, SCSI ID=7, 32/255 SCBs (scsi1) Downloading sequencer code... 383 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 (scsi0:0:0:0) Synchronous at 40.0 Mbyte/sec, offset 8. Vendor: SEAGATE Model: ST39173LW Rev: 6246 Type: Direct-Access ANSI SCSI revision: 02 (scsi1:0:2:0) Synchronous at 10.0 Mbyte/sec, offset 15. Vendor: SEAGATE Model: ST15150N Rev: 4611 Type: Direct-Access ANSI SCSI revision: 02 (scsi1:0:4:0) Synchronous at 10.0 Mbyte/sec, offset 15. Vendor: NAKAMICH Model: MJ-5.16S Rev: 1.02 Type: CD-ROM ANSI SCSI revision: 02 Vendor: NAKAMICH Model: MJ-5.16S Rev: 1.02 Type: CD-ROM ANSI SCSI revision: 02 Vendor: NAKAMICH Model: MJ-5.16S Rev: 1.02 Type: CD-ROM ANSI SCSI revision: 02 Vendor: NAKAMICH Model: MJ-5.16S Rev: 1.02 Type: CD-ROM ANSI SCSI revision: 02 Vendor: NAKAMICH Model: MJ-5.16S Rev: 1.02 Type: CD-ROM ANSI SCSI revision: 02 (scsi1:0:5:0) Synchronous at 10.0 Mbyte/sec, offset 15. Vendor: TEAC Model: CD-R56S4 Rev: 1.0P Type: CD-ROM ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 0, id 0, lun 0 Detected scsi disk sdb at scsi1, channel 0, id 2, lun 0 SCSI device sda: 17783240 512-byte hdwr sectors (9105 MB) sda: sda1 sda2 sda3 sda4 SCSI device sdb: 8388315 512-byte hdwr sectors (4295 MB) sdb: sdb1 Detected scsi CD-ROM sr0 at scsi1, channel 0, id 4, lun 0 Detected scsi CD-ROM sr1 at scsi1, channel 0, id 4, lun 1 Detected scsi CD-ROM sr2 at scsi1, channel 0, id 4, lun 2 Detected scsi CD-ROM sr3 at scsi1, channel 0, id 4, lun 3 Detected scsi CD-ROM sr4 at scsi1, channel 0, id 4, lun 4 Detected scsi CD-ROM sr5 at scsi1, channel 0, id 5, lun 0 sr0: scsi3-mmc drive: 16x/16x xa/form2 changer sr0: CDROM (ioctl) reports ILLEGAL REQUEST. sr1: scsi3-mmc drive: 16x/16x xa/form2 changer sr1: CDROM (ioctl) reports ILLEGAL REQUEST. sr2: scsi3-mmc drive: 16x/16x xa/form2 changer sr2: CDROM (ioctl) reports ILLEGAL REQUEST. sr3: scsi3-mmc drive: 16x/16x xa/form2 changer sr3: CDROM (ioctl) reports ILLEGAL REQUEST. sr4: scsi3-mmc drive: 16x/16x xa/form2 changer sr4: CDROM (ioctl) reports ILLEGAL REQUEST. sr5: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray -- Rafael PS. By the way, it's not necessary to cc 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: observations with asus cuv4x-d
On Sat, Mar 17, 2001 at 01:08:19AM +0100, Oliver Paukstadt wrote: > HY HY > > I changed my motherboard to a asus cuv4x-d with 2 PIII-800. > > With MPS 1.4 enabled (BIOS), i'll get > probable hardware bug: clock timer configuration lost - probably a VIA686a > motherboard (linux/arch/i386/kernel/time.c) > I use 2.4.2-ac20 > > Disabling MPS1.4 causes the Board to work without any problems. Spec says CUV4x-d is 686B. :wq --William Park, Open Geometry Consulting, Linux/Python, 8 CPUs. - 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]: Only one memory zone for sparc64
> I'd be surprised if dbench was anything other than disk-bound on most > systems. On any of my machines, the standard error of a single dbench > run is *way* larger than 1%, and I'd expect to have to run the > benchmark a dozen times to get a confidence interval small enough to > detect a 1% performance change: are your runs repeatable enough to be > this sensitive to the effect of the allocator? With 2G RAM and: kill -STOP echo "90 64 64 256 5120 30720 95 0 0" > /proc/sys/vm/bdflush I dont do one single disk interrupt for a dbench 60 :) At this stage dbench runs become more repeatable. Anton - 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/Patch] Device Registry
Tim, what is it that this is designed to do that devfs doesn't (or can't) do? David Lang On Sat, 17 Mar 2001, Tim Jansen wrote: > Date: Sat, 17 Mar 2001 03:10:33 +0100 > From: Tim Jansen <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: [RFC/Patch] Device Registry > > RFC: Linux Device Registry > == > > Summary > --- > The device registry provides a /proc file in text format that contains > a list of all connected physical devices. Each list entry > includes (as far as available) the name and vendor of the device, its > location/topological information, the device files (/dev) that the > driver(s) have registered and a unique DeviceID that makes it possible to > find the device after a reboot. > An experimental patch for 2.4.2 can be found at http://www.tjansen.de/devreg > > > Reasons for the Device Registry > --- > Finding the available devices with the current Linux kernel is difficult > and not always possible. For example the only way to get all printers on > Linux is to open all devices in /dev that could represent one, but > this has some limitations. The first problem is that the user-space app must > know which files should be probed. The /dev/lpX files are candidates > and for USB printers also /dev/usb/lpX. Everytime a new bus for printers > is added there is a new range of device files that must be probed, for > example for IEEE1394/FireWire printers user-space apps would have to probe > the /dev/ieee1394/lpX (or whatever their names will be). This makes it > impossible to write forward-compatible user-space applications. > > Even if the application knows which devices are actual printers they > must be presented to the user so that he can select one of them, > and for this things like the printers name and vendor are neccessary. > Unfortunately every bus has a different facility to provide these > information. Parallel ports expose them in /proc/sys/dev/parport; USB > shows them in usbdevfs, but it is not possible to figure out which > /dev/usb/lpX file belongs to which physical printer. And as IEEE1394 will > have to implement another method to get information about the printer > device, user-apps today have no chance to get show them when kernel support is > ready. > > The next problem is associated with hotplugging. If you have two printers > attached to the USB bus, say an Epson and a HP printer, you dont know > their device files. If you turn on the Epson printer and then the HP printer, > the Epson will be /dev/usb/lp0 and the HP /dev/usb/lp1. When you first > power on the HP on the next reboot (or turn off the Epson before you turn the > HP on) it will be on /dev/usb/lp0. > > Sometimes devices have several independent interfaces that belong together. > For example there are USB scanners with buttons that are intended to trigger > actions by user-space applications like starting a scan. The USB driver uses > two separate drivers for them, in the case of a scanner it would use a HID > driver (there is a patch available for non-keyboards/mice/joystick input > devices) and a regular scanner driver. A similar setup is also common for USB > audio devices. > With the current implementation it is not possible to find out which device > files represent which physical device. > > > Solutions provided by the Device Registry > - > The Device Registry (DevReg) puts a text list of all physical devices > into /proc/devreg. Each entry consists of: > > - the model and vendor name of the device (if available) > - the type of the device (for example hub/usb) > - the bus/location of the device (for example COM2 or USB) > - topology information (to build a tree of all devices) > - the unique DeviceID to find the device after a reboot > - the device files (if devfs is used) and the major/minor number of > the device files and the interface it implements (for example OSS or V4L) > > This should be sufficient for the following use cases: > - find all devices that implement a interface (for example > all OSS devices) and present them to the user he can chose one > - get the DeviceID of a device so its device file can be found after a > reboot > - find a device file for a DeviceID > - show all devices in the computer > > Finding a device with a DeviceID instead of a device file name is neither > supported by current applications nor by other Unix-like operating > systems. Therefore, to stay compatible with existing software, a user-space > daemon could take care of creating stable names for devices. > For example, if you have the Epson and HP printer from the example above, > the daemon could create two symlinks called /dev/lpEpson and /dev/lpHP that > always point to the correct device file as long as the physical device is > connected. > As the format of the /proc/devreg file is relatively complex a user-space > library that implements the use cases given above will be provided. > > > DeviceID > --
Re: parport not detected
> The parallel port is not being detected on my ABIT KT7A KT133 w/ Athlon Also try comp.os.linux.hardware. BIOS 278/irq5 378/irq7 EPP 1.9 .config --- CONFIG_PARPORT=y CONFIG_PARPORT_PC=y CONFIG_PNP=y CONFIG_PNP_PARPORT=y CONFIG_PRINTER=y CONFIG_PRINTER_READBACK=y kernal boot params -- append="parport=0x378,7 parport=0x278,5" options for /etc/rc.d/rc.local -- # abort on error, careful error check, trust IRQ. # see tunelp(8) & /usr/src/linux/drivers/misc/lp.c /usr/sbin/tunelp /dev/lp0 -a on -o on -T on /usr/sbin/tunelp /dev/lp1 -a on -o on -T on looks like this (lp1 was powered down at boot time) Feb 25 02:57:39 dell kernel: parport0: PC-style at 0x378, irq 7 [SPP,PS2,EPP] Feb 25 02:57:39 dell kernel: parport0: Printer, Hewlett-Packard HP LaserJet 1100 Feb 25 02:57:39 dell kernel: parport1: PC-style at 0x278, irq 5 [SPP,PS2,EPP] Feb 25 02:57:39 dell kernel: parport1: no IEEE-1284 device present. Feb 25 02:57:40 dell kernel: lp0: using parport0 (interrupt-driven). Feb 25 02:57:40 dell kernel: lp1: using parport1 (interrupt-driven). -- - 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: Kernel 2.4.2-ac20
On Sat, 17 Mar 2001, Keith Owens wrote: Thanks Keith for your note. I will check out your 'points' and see what happens. Anything is possible.. > Date: Sat, 17 Mar 2001 12:57:36 +1100 > From: Keith Owens <[EMAIL PROTECTED]> > To: Ted Gervais <[EMAIL PROTECTED]> > Subject: Re: Kernel 2.4.2-ac20 > > On Fri, 16 Mar 2001 11:40:42 -0400 (AST), > Ted Gervais <[EMAIL PROTECTED]> wrote: > >unix:/etc# insmod soundmodem > >Using /lib/modules/2.4.2-ac20/kernel/drivers/net/hamradio/soundmodem/soundmodem.o > >/lib/modules/2.4.2-ac20/kernel/drivers/net/hamradio/soundmodem/soundmodem.o: >unresolved symbol hdlcdrv_transmitter_Rc7c3 > > Either you forgot to load hdlcdrv.o first (modprobe soundmodem would be > better than insmod soundmodem) or you have been bitten by the broken > Makefiles (see http://www.tux.org/lkml/#s8-8). > --- Earth is a beta site. Ted Gervais <[EMAIL PROTECTED]> 44.135.34.201 linux.ve1drg.ampr.org - 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/
[RFC/Patch] Device Registry
RFC: Linux Device Registry == Summary --- The device registry provides a /proc file in text format that contains a list of all connected physical devices. Each list entry includes (as far as available) the name and vendor of the device, its location/topological information, the device files (/dev) that the driver(s) have registered and a unique DeviceID that makes it possible to find the device after a reboot. An experimental patch for 2.4.2 can be found at http://www.tjansen.de/devreg Reasons for the Device Registry --- Finding the available devices with the current Linux kernel is difficult and not always possible. For example the only way to get all printers on Linux is to open all devices in /dev that could represent one, but this has some limitations. The first problem is that the user-space app must know which files should be probed. The /dev/lpX files are candidates and for USB printers also /dev/usb/lpX. Everytime a new bus for printers is added there is a new range of device files that must be probed, for example for IEEE1394/FireWire printers user-space apps would have to probe the /dev/ieee1394/lpX (or whatever their names will be). This makes it impossible to write forward-compatible user-space applications. Even if the application knows which devices are actual printers they must be presented to the user so that he can select one of them, and for this things like the printers name and vendor are neccessary. Unfortunately every bus has a different facility to provide these information. Parallel ports expose them in /proc/sys/dev/parport; USB shows them in usbdevfs, but it is not possible to figure out which /dev/usb/lpX file belongs to which physical printer. And as IEEE1394 will have to implement another method to get information about the printer device, user-apps today have no chance to get show them when kernel support is ready. The next problem is associated with hotplugging. If you have two printers attached to the USB bus, say an Epson and a HP printer, you dont know their device files. If you turn on the Epson printer and then the HP printer, the Epson will be /dev/usb/lp0 and the HP /dev/usb/lp1. When you first power on the HP on the next reboot (or turn off the Epson before you turn the HP on) it will be on /dev/usb/lp0. Sometimes devices have several independent interfaces that belong together. For example there are USB scanners with buttons that are intended to trigger actions by user-space applications like starting a scan. The USB driver uses two separate drivers for them, in the case of a scanner it would use a HID driver (there is a patch available for non-keyboards/mice/joystick input devices) and a regular scanner driver. A similar setup is also common for USB audio devices. With the current implementation it is not possible to find out which device files represent which physical device. Solutions provided by the Device Registry - The Device Registry (DevReg) puts a text list of all physical devices into /proc/devreg. Each entry consists of: - the model and vendor name of the device (if available) - the type of the device (for example hub/usb) - the bus/location of the device (for example COM2 or USB) - topology information (to build a tree of all devices) - the unique DeviceID to find the device after a reboot - the device files (if devfs is used) and the major/minor number of the device files and the interface it implements (for example OSS or V4L) This should be sufficient for the following use cases: - find all devices that implement a interface (for example all OSS devices) and present them to the user he can chose one - get the DeviceID of a device so its device file can be found after a reboot - find a device file for a DeviceID - show all devices in the computer Finding a device with a DeviceID instead of a device file name is neither supported by current applications nor by other Unix-like operating systems. Therefore, to stay compatible with existing software, a user-space daemon could take care of creating stable names for devices. For example, if you have the Epson and HP printer from the example above, the daemon could create two symlinks called /dev/lpEpson and /dev/lpHP that always point to the correct device file as long as the physical device is connected. As the format of the /proc/devreg file is relatively complex a user-space library that implements the use cases given above will be provided. DeviceID Each device get a unique device id. The id is a string in the format "bus-type/location/model/serialnum". bus-type is "usb" or "pci" for the currently supported busses. location is "busnumber:slotnumber" for PCI devices and "busnumber[:1st-hub-model:1st-hub-vendor[:2nd-hub-model:2nd-hub-vendor..]]" for USB devices. The format of the model is "vendorID:deviceID" for both USB and PCI. The serial number is dr
Re: scsi_scan problem.
Doug Ledford wrote: > It would still be helpful because this problem has to be fixed before 2.5. > The only question is whether to fix it with a simple patch such as I just > submitted, or a more complex patch that uses REPORT LUNs. Part of that answer > is how my simple patch works on your device. Hi, I applied the patch, and found no ill-effect. The multi-lun devices I have only supports non-hard disk drive types. On dc390 adaptor(tmscsim): target:5 Two (2) Lun device. Matsushita (panasonic) CD/PD combo. target:6 Seven(7) lun device. Nakamichi MBR Cd changer. These devices seem to report all LUN's as available even if the media is not in the drive. The driver, tmscsim.o, is compiled as module and is inserted during boot (using Debian's /etc/module mechanism). Eg. Device config. ishikawa@duron$ cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 04 Lun: 00 Vendor: HITACHI Model: DK318H-91WS Rev: B2BQ Type: Direct-AccessANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 05 Lun: 00 Vendor: MATSHITA Model: PD-1 LF-1000 Rev: A111 Type: Optical Device ANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 05 Lun: 01 Vendor: MATSHITA Model: PD-1 LF-1000 Rev: A111 Type: CD-ROM ANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 06 Lun: 00 Vendor: NRC Model: MBR-7Rev: 110 Type: CD-ROM ANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 06 Lun: 01 Vendor: NRC Model: MBR-7Rev: 110 Type: CD-ROM ANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 06 Lun: 02 Vendor: NRC Model: MBR-7Rev: 110 Type: CD-ROM ANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 06 Lun: 03 Vendor: NRC Model: MBR-7Rev: 110 Type: CD-ROM ANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 06 Lun: 04 Vendor: NRC Model: MBR-7Rev: 110 Type: CD-ROM ANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 06 Lun: 05 Vendor: NRC Model: MBR-7Rev: 110 Type: CD-ROM ANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 06 Lun: 06 Vendor: NRC Model: MBR-7Rev: 110 Type: CD-ROM ANSI SCSI revision: 02 ishikawa@duron$ >From dmesg output: I deleted devfs debug messages from below. Linux version 2.4.2 (root@duron) (gcc version 2.95.2 2220 (Debian GNU/Linux) ) #35 Sat Mar 17 10:35:57 JST 2001 ... Kernel command line: devfs=mount,dmod,dreg,dilookup root=/dev/sda6 ro scsihosts= sym53c8xx:tmscsim BOOT_IMAGE=242-doug.pat Initializing CPU#0 ... ... DC390: 1 adapters found scsi1 : Tekram DC390/AM53C974 V2.0f 2000-12-20 Vendor: MATSHITA Model: PD-1 LF-1000 Rev: A111 Type: Optical Device ANSI SCSI revision: 02 Detected scsi removable disk sdb at scsi1, channel 0, id 5, lun 0 Vendor: MATSHITA Model: PD-1 LF-1000 Rev: A111 Type: CD-ROM ANSI SCSI revision: 02 Vendor: NRC Model: MBR-7 Rev: 110 Type: CD-ROM ANSI SCSI revision: 02 Vendor: NRC Model: MBR-7 Rev: 110 Type: CD-ROM ANSI SCSI revision: 02 Vendor: NRC Model: MBR-7 Rev: 110 Type: CD-ROM ANSI SCSI revision: 02 Vendor: NRC Model: MBR-7 Rev: 110 Type: CD-ROM ANSI SCSI revision: 02 Vendor: NRC Model: MBR-7 Rev: 110 Type: CD-ROM ANSI SCSI revision: 02 Vendor: NRC Model: MBR-7 Rev: 110 Type: CD-ROM ANSI SCSI revision: 02 Vendor: NRC Model: MBR-7 Rev: 110 Type: CD-ROM ANSI SCSI revision: 02 sg_init called: 1 ... ... The following is reported since the ... target : 5 , lun : 0 is an optical PD drive and ... it seemed to be treated as if it were a removable hard disk. ... Since no media was in the tray when the system booted ... the error is repoted. ... (Note that /dev/sda is Hitachi hard disk.) sdb : READ CAPACITY failed. sdb : status = 1, message = 00, host = 0, driver = 28 sdb : extended sense code = 2 sdb : block size assumed to be 512 bytes, disk size 1GB. /dev/scsi/host1/bus0/target5/lun0: I/O error: dev 08:10, sector 0 unable to read partition table ... ... I ran "modprobe sr_mod" ... init_sr: pid=425 [comm=modprobe] ppid=424 [comm=bash] Detected scsi CD-ROM sr0 at scsi1, channel 0, id 5, lun 1 Detected scsi CD-ROM sr1 at scsi1, channel 0, id 6, lun 0 Detected scsi CD-ROM sr2 at scsi1, channel 0, id 6, lun 1 Detected scsi CD-ROM sr3 at scs
Re: Kernel 2.4.2-ac20
On Fri, 16 Mar 2001 11:40:42 -0400 (AST), Ted Gervais <[EMAIL PROTECTED]> wrote: >unix:/etc# insmod soundmodem >Using /lib/modules/2.4.2-ac20/kernel/drivers/net/hamradio/soundmodem/soundmodem.o >/lib/modules/2.4.2-ac20/kernel/drivers/net/hamradio/soundmodem/soundmodem.o: >unresolved symbol hdlcdrv_transmitter_Rc7c3 Either you forgot to load hdlcdrv.o first (modprobe soundmodem would be better than insmod soundmodem) or you have been bitten by the broken Makefiles (see http://www.tux.org/lkml/#s8-8). - 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: scsi_scan problem.
Patrick Mansfield wrote: > If your testing Doug's patch, it might be a good idea to run with/without > your adapter built as a module, as the kernel is inconsistent in its setting > of "online" in scsi.c: it sets online TRUE after an attach in > scsi_register_device_module(), but leaves online as is after an > attach in scsi_register_host(). Grrr...I hate these kinds of inconsistencies. They don't belong there. Whether a driver is a module or compiled in should not effect whether or not an attached device is considered valid. > So, if the scan_scsis set online FALSE, it sometimes is set back to TRUE; > otherwise, I don't think any other code will set online to TRUE (once it > is set to FALSE after its scanned, no one can even open the device, not even sg). This is the case for what I was seeing (but, all of the offline entries used up all 40 SCSI disk structs that were available for use, so if I brought another controller online there would be no available disk slots). > The online = TRUE should probably be removed from scsi_register_device_module(), > as disks with peripheral qualifier 1 (like Doug's the Clariion storage) > ususally complain when sent a READ CAPACITY. I got such errors when running with > a Clariion DASS (DGC RAID/DISK, scsi attached disk array). > > Doug - did you try running with/without your adapter built as a module? I'd > expect you to get a READ CAPACITY failure for each LUN with PQ 1. All modular, but none of the disks on mine ever got the error you are mentioning. Could possibly be because my root disk is on an aic7xxx and the array on a qla2x00 that I did *not* let be included in the initrd so I could bring it up after the rest of the boot was complete. This, of course, implies that sd_mod was loaded well before the qla2x00 and if I read your above comments correctly, that means it scanned the array from someplace other than scsi_register_device_module() and hence didn't get hit by the problem you are referring to. In fact, I would guess the problem you are referring to only happens when a driver module is loaded prior to sd_mod.o, and that reversing the order will solve the problem (but, I haven't looked so I could easily be wrong ;-) -- Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford Please check my web site for aic7xxx updates/answers before e-mailing me about problems - 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: IDE poweroff -> hangup
On Sat, 17 Mar 2001, CODEZ wrote:
> Andrew wrote.
Oh and and it is "Andre" with an accent grav
> > All of the 440*X Chipsets using a PIIX4/PIIX4AB/PIIX4EB are broken beyond
> > repair. Several weeks ago, the old hat and I discussed the issue and
> > after sending him the same docs I have from Intel, we both laugh because
> > the errata clear states "NO FIX"
>
>
> Well andrew,
> I yet have to find something like absolute perfect in the technology domain,
> me agree with you that the following chipsets are broken but then there
> is'nt any for which any of us can claim that it'z not broken or will not in
> sometimez in future, anyway here is some information that i think guruz
> dealing with ATA development must know about it to bring sanity of those who
> are not guruz.
I try but I see one of us missed the boat
> At the time of (e-ide) driver initialisation
> (LOG)
> Uniform Multi-Platform E-IDE driver Revision: 6.31
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> PIIX4: IDE controller on PCI bus 00 dev 21
> PIIX4: chipset revision 1
> PIIX4: not 100% native mode: will probe irqs later
> ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:pio
> ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:pio
> hda: ST317221A, ATA DISK drive
> hdc: CRD-8480M, ATAPI CD/DVD-ROM drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> hda: 33683328 sectors (17246 MB) w/512KiB Cache, CHS=2096/255/63, UDMA(33)
> *hm why this*
> hdc: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
> hdc: set_drive_speed_status: error=0xb4
> hdc: ATAPI 48X CD-ROM drive, 128kB Cache, DMA
> Uniform CD-ROM driver Revision: 3.12
>
> After pokin through the /proc/ide/*/hdx/settings i found
>
> name value min max mode
> - --- ---
> breada_readahead4 0 127 rw
> current_speed 66 0 69 rw
Just maybe if you did some math!
66 == 0x42 that is Ultra 33
64 == 0x40 that is Ultra 16
65 == 0x41 that is Ultra 25
66 == 0x42 that is Ultra 33
67 == 0x43 that is Ultra 44
68 == 0x44 that is Ultra 66
69 == 0x45 that is Ultra 100
> *check this*
> dsc_overlap 0 0 1 rw
> file_readahead 0 0 2097151 rw
> ide_scsi0 0 1 rw
> init_speed 66 0 69 rw
Did it not occur to you that a max speed of Ultra 69 is stupid??
> *check this*
> io_32bit0 0 3 rw
> keepsettings0 0 1 rw
> max_kb_per_request 64 1 127 rw
> nice1 1 0 1 rw
> number 2 0 3 rw
> pio_modewrite-only 0 255 w
> slow0 0 1 rw
> unmaskirq 0 0 1 rw
> using_dma 1 0 1 rw
>
> AFAIK inetl's 82371AB chipset never supported UDMA 66 mode then why driver
> initialised it like this...
> Right now i placed a line somewhere in my rc.sysinit script
> hdpatm -d1 -X34 /dev/hdX to reslove the dead lock i was facing whenever
Oh
34 == 0x22 MultiWord DMA mode 2
33 == 0x21 MultiWord DMA mode 1
32 == 0x20 MultiWord DMA mode 0
18 == 0x12 SingleWord DMA mode 2
17 == 0x11 SingleWord DMA mode 1
16 == 0x10 SingleWord DMA mode 0
Just maybe you can see that the timings for HEX represented values are ==
8421:8421
RUMS:
R == Reserved
U == Ultra
M == MultiWord
S == SingleWord
> tried to mount the specified drive.
>
> Any suggestion
Read before blowing heat, I wear asbestos!
> Regardz
> daCodez
>
>
>
> **
> Simplicity is the only comlexity I know about.
>
>
>
>
>
>
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/
Announce: ksymoops 2.4.1 is available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Content-Type: text/plain; charset=us-ascii Mirror at ftp://ftp..kernel.org/pub/linux/utils/kernel/ksymoops/v2.4 ksymoops-2.4.1.tar.gz Source tarball, includes RPM spec file ksymoops-2.4.1-1.src.rpmAs above, in SRPM format ksymoops-2.4.1-1.i386.rpm Compiled with egcs-2.91.66, glibc 2.1.2 ksymoops-2.4.1-1.sparc.rpm Compiled as 32 bit user space, it supports 64 bit kernels. ksymoops-2.4.1-1.ia64.rpm Compiled with gcc 2.96-ia64-000717 snap 001117, libc-2.2.1. Changelog extract * Accept any 'Bad ' text in EIP. * Add long option names. * Recent modutils has support for ksymoops, update ksymoops man page. * White space clean up. * Remove deprecated gcc extensions. This time I remembered to bump the version number ;). -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.3 (GNU/Linux) Comment: Exmh version 2.1.1 10/15/1999 iD8DBQE6ssJgi4UHNye0ZOoRAhlHAJ9LcNSy4n1uyj6fvyUmRHhBnNSlLgCgyxCU cHq6zvGs2KE86uJ6rydW0DI= =JVZt -END PGP SIGNATURE- - 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] Improved version reporting
> {Shrug} Thinking isn't sufficient - check your facts.
Poor Riley,
Probably I should not answer, I think you know all the facts already.
But just to be sure:
(i) There are two different packages, kbd and a forked version,
console-tools. Both contain roughly the same programs.
In your earlier mails you seemed aware of that, but now you report
that the console-tools version of loadkeys does not want to
print a kbd version. No surprise there.
(ii) I am the maintainer of both mount and util-linux.
If I say that there exists no more recent version of mount
than the one found in util-linux, you can believe me.
Andries
-
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: Cannot delete dir
On Fri, 16 Mar 2001, Neal Gieselman wrote: >Date: Fri, 16 Mar 2001 10:42:40 -0600 >From: Neal Gieselman <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Content-Type: text/plain >Subject: Cannot delete dir > >Excuse me, but can anyone tell me how I might delete a directory on a Redhat >6.1 ext2 file >system that has permissions drwS--sr-x? Even as root I cannot unlink the >directory. What does "lsattr" say? I'll bet you've had some fs corruption and some extended attributes are enabled. Also be sure to look at the attributes of the parent directory as well. man lsattr man chattr -- Mike A. Harris - Linux advocate - Free Software advocate This message is copyright 2001, all rights reserved. Views expressed are my own, not necessarily shared by my employer. -- There are two major products that come out of Berkeley: LSD and BSD. We don't believe this to be a coincidence. -- Jeremy S. Anderson - 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: IDE poweroff -> hangup
Andrew wrote.
> All of the 440*X Chipsets using a PIIX4/PIIX4AB/PIIX4EB are broken beyond
> repair. Several weeks ago, the old hat and I discussed the issue and
> after sending him the same docs I have from Intel, we both laugh because
> the errata clear states "NO FIX"
Well andrew,
I yet have to find something like absolute perfect in the technology domain,
me agree with you that the following chipsets are broken but then there
is'nt any for which any of us can claim that it'z not broken or will not in
sometimez in future, anyway here is some information that i think guruz
dealing with ATA development must know about it to bring sanity of those who
are not guruz.
At the time of (e-ide) driver initialisation
(LOG)
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev 21
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:pio
hda: ST317221A, ATA DISK drive
hdc: CRD-8480M, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 33683328 sectors (17246 MB) w/512KiB Cache, CHS=2096/255/63, UDMA(33)
*hm why this*
hdc: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
hdc: set_drive_speed_status: error=0xb4
hdc: ATAPI 48X CD-ROM drive, 128kB Cache, DMA
Uniform CD-ROM driver Revision: 3.12
After pokin through the /proc/ide/*/hdx/settings i found
name value min max mode
- --- ---
breada_readahead4 0 127 rw
current_speed 66 0 69 rw
*check this*
dsc_overlap 0 0 1 rw
file_readahead 0 0 2097151 rw
ide_scsi0 0 1 rw
init_speed 66 0 69 rw
*check this*
io_32bit0 0 3 rw
keepsettings0 0 1 rw
max_kb_per_request 64 1 127 rw
nice1 1 0 1 rw
number 2 0 3 rw
pio_modewrite-only 0 255 w
slow0 0 1 rw
unmaskirq 0 0 1 rw
using_dma 1 0 1 rw
AFAIK inetl's 82371AB chipset never supported UDMA 66 mode then why driver
initialised it like this...
Right now i placed a line somewhere in my rc.sysinit script
hdpatm -d1 -X34 /dev/hdX to reslove the dead lock i was facing whenever
tried to mount the specified drive.
Any suggestion
Regardz
daCodez
**
Simplicity is the only comlexity I know about.
-
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: [Acpi] [PATCH] USB suspend when no devices attached
On Fri, Mar 16, 2001, Grover, Andrew <[EMAIL PROTECTED]> wrote: > This is a preliminary patch against 2.4.2 to uhci.c that puts the host > controller into global suspend when there are no devices attached. This > conserves power on mobile systems, and because suspending the host > controller ceases UHCI's incessant busmastering activity, it allows the CPU > to enter a deeper idle state. > > The main problem with this implementation is that it just looks at the 2 > root hub ports and suspends if nothing is connected. Ideally, it would be > smart enough to realize it can also suspend when only hubs are present, or > when all devices on the USB are also suspended. I hope a USB expert can add > these enhancements, as it's beyond me. If you want it to be seamless, you really can't do that. USB is a polled bus, so the HC needs to send something to the device so it tells us that something has changed, like a device being plugged into a hub (not the root hub). > You should be able to verify this patch is working in one of two ways: > 1) Turn on USB debug messages, and look for suspend_hc and wakeup_hc > messages > 2) Download the latest ACPI patch from > http://developer.intel.com/technology/iapc/acpi/downloads.htm and verify > that /proc/acpi/processor/0/status shows mostly 0's for busmastering > activity (as opposed to mostly F's) when no USB devices are connected. Thanks for the patch. I'll integrate into my patch and send it off to Linus as well after I run it through it's paces. It looks good on visual inspection atleast. JE - 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] USB suspend when no devices attached
Hi all. This is a preliminary patch against 2.4.2 to uhci.c that puts the host controller into global suspend when there are no devices attached. This conserves power on mobile systems, and because suspending the host controller ceases UHCI's incessant busmastering activity, it allows the CPU to enter a deeper idle state. The main problem with this implementation is that it just looks at the 2 root hub ports and suspends if nothing is connected. Ideally, it would be smart enough to realize it can also suspend when only hubs are present, or when all devices on the USB are also suspended. I hope a USB expert can add these enhancements, as it's beyond me. You should be able to verify this patch is working in one of two ways: 1) Turn on USB debug messages, and look for suspend_hc and wakeup_hc messages 2) Download the latest ACPI patch from http://developer.intel.com/technology/iapc/acpi/downloads.htm and verify that /proc/acpi/processor/0/status shows mostly 0's for busmastering activity (as opposed to mostly F's) when no USB devices are connected. Thanks -- Regards -- Andy uhci.diff
observations with asus cuv4x-d
HY HY I changed my motherboard to a asus cuv4x-d with 2 PIII-800. With MPS 1.4 enabled (BIOS), i'll get probable hardware bug: clock timer configuration lost - probably a VIA686a motherboard (linux/arch/i386/kernel/time.c) I use 2.4.2-ac20 Disabling MPS1.4 causes the Board to work without any problems. BYtE Oli +++LINUX++ +++Manchmal stehe ich sogar nachts auf und installiere mir eins+++ ++ - 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: New ld must have --oformat instead of -oformat ?
On Fri, 16 Mar 2001, Michael Bacarella wrote: > Riding the bleeding edge of debian leaves some interesting tastes. > The line 'ld: cannot open binary: No such file or directory' is puzzling. > The Makefile only has one dash. Changing -oformat to --oformat in > arch/i386/boot/Makefile builds the kernel just fine. Correct fix. (Already in 2.4.2-ac, and 2.4.3-pre) > Did I stumble onto something that is a non-issue or am I just lucky enough > to be the first one to trip over it? It came up a few weeks ago. It's only an issue in that 2.4.3 hasn't been released yet, so you'll need to apply one of the above mentioned patchsets. (Or do it by hand as you already did :) regards, Dave. -- | Dave Jones.http://www.suse.de/~davej | SuSE Labs - 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: scsi_scan problem.
> > I applied the first hunk to version 2.4.3-pre4, as by email with Doug. > The output for the scsi devices follows and is identical with and > without the patch. Maybe someone can explain the meaning of the illegal > requests at the end. Nevertheless, I can use the drive fine. > If your testing Doug's patch, it might be a good idea to run with/without your adapter built as a module, as the kernel is inconsistent in its setting of "online" in scsi.c: it sets online TRUE after an attach in scsi_register_device_module(), but leaves online as is after an attach in scsi_register_host(). So, if the scan_scsis set online FALSE, it sometimes is set back to TRUE; otherwise, I don't think any other code will set online to TRUE (once it is set to FALSE after its scanned, no one can even open the device, not even sg). The online = TRUE should probably be removed from scsi_register_device_module(), as disks with peripheral qualifier 1 (like Doug's the Clariion storage) ususally complain when sent a READ CAPACITY. I got such errors when running with a Clariion DASS (DGC RAID/DISK, scsi attached disk array). Doug - did you try running with/without your adapter built as a module? I'd expect you to get a READ CAPACITY failure for each LUN with PQ 1. -- Patrick Mansfield - 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: kernel 2.4.2 network performances
On Thu, Mar 15, 2001 at 03:42:37PM +0200, Sampsa Ranta wrote: > Yesterday I discovered that the load I can throw out to network seems to > depend on other activities running on machine. I was able to get > throughput of 33M/s with ATM when machine was idle, while I compiled > kernel at same time, the throughput was 135M/s. > > So, I suggest you try to compile kernel while running your UDP stream! Try raising HZ. Perhaps your driver depends on it. It shouldn't, but who knows. Regards, bert -- http://www.PowerDNS.com Versatile DNS Services Trilab The Technology People 'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet - 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/
[Fwd: problems compiling scsi_ioctl on kernels later 2.4.1]
make -C scsi make[2]: Entering directory `/usr/src/linux/drivers/scsi' make -C aic7xxx make[3]: Entering directory `/usr/src/linux/drivers/scsi/aic7xxx' make all_targets make[4]: Entering directory `/usr/src/linux/drivers/scsi/aic7xxx' ld -m elf_i386 -r -o aic7xxx_mod.o aic7xxx_linux.o aic7xxx_linux_pci.o aic7xxx_proc.o aic7770_linux.o aic7xxx.o aic7xxx_pci.o aic7xxx_93cx6.o aic7770.o rm -f aic7xxx_drv.o ld -m elf_i386 -r -o aic7xxx_drv.o aic7xxx_mod.o make[4]: Leaving directory `/usr/src/linux/drivers/scsi/aic7xxx' make[3]: Leaving directory `/usr/src/linux/drivers/scsi/aic7xxx' make all_targets make[3]: Entering directory `/usr/src/linux/drivers/scsi' gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -march=i586-c -o scsi_ioctl.o scsi_ioctl.c scsi_ioctl.c:191: parse error before `Scsi_Ioctl_Command' scsi_ioctl.c:192: warning: function declaration isn't a prototype scsi_ioctl.c: In function `scsi_ioctl_send_command': scsi_ioctl.c:204: `sic' undeclared (first use in this function) scsi_ioctl.c:204: (Each undeclared identifier is reported only once scsi_ioctl.c:204: for each function it appears in.) scsi_ioctl.c:209: `Scsi_Ioctl_Command' undeclared (first use in this function) scsi_ioctl.c:212: warning: type defaults to `int' in declaration of `type name' scsi_ioctl.c:213: warning: type defaults to `int' in declaration of `type name' scsi_ioctl.c:271: `dev' undeclared (first use in this function) scsi_ioctl.c: In function `scsi_ioctl': scsi_ioctl.c:378: `Scsi_Idlun' undeclared (first use in this function) scsi_ioctl.c:381: parse error before `)' scsi_ioctl.c:382: parse error before `)' scsi_ioctl.c:385: warning: type defaults to `int' in declaration of `type name' scsi_ioctl.c:385: parse error before `)' scsi_ioctl.c:385: parse error before `)' scsi_ioctl.c:385: warning: type defaults to `int' in declaration of `type name' scsi_ioctl.c:385: parse error before `)' scsi_ioctl.c:385: parse error before `)' scsi_ioctl.c:385: warning: type defaults to `int' in declaration of `type name' scsi_ioctl.c:385: parse error before `)' scsi_ioctl.c:386: parse error before `)' scsi_ioctl.c:386: parse error before `)' scsi_ioctl.c:386: warning: type defaults to `int' in declaration of `type name' scsi_ioctl.c:386: parse error before `)' scsi_ioctl.c:386: parse error before `)' scsi_ioctl.c:386: warning: type defaults to `int' in declaration of `type name' scsi_ioctl.c:386: parse error before `)' scsi_ioctl.c:386: parse error before `)' scsi_ioctl.c:386: warning: type defaults to `int' in declaration of `type name' scsi_ioctl.c:386: parse error before `)' scsi_ioctl.c:412: `Scsi_Ioctl_Command' undeclared (first use in this function) scsi_ioctl.c:412: parse error before `)' scsi_ioctl.c:419: `SCSI_REMOVAL_PREVENT' undeclared (first use in this function) scsi_ioctl.c:429: `SCSI_REMOVAL_ALLOW' undeclared (first use in this function) make[3]: *** [scsi_ioctl.o] Error 1 make[3]: Leaving directory `/usr/src/linux/drivers/scsi' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/usr/src/linux/drivers/scsi' make[1]: *** [_subdir_scsi] Error 2 make[1]: Leaving directory `/usr/src/linux/drivers' make: *** [_dir_drivers] Error 2 i had it working fine in 2.4.1 Douglas Gilbert schreef: > > i tried to compile linux-2.4.3-pre4 on a redhat and suse machine with > > different gcc's egcs 1.1.2 ,gcc 2.96 and gcc 2.95 > > but all get stuck on compiling scsi_ioctl in kernel or as module > > does anyone have an idea? > > machine's : -pentium 66 (with bug :=) running suse 7.0 > > -amd athlon 1000 with promise fasttrak running redhat > > 7.0 > > Erik, > Is there a compile error (if so what). There are no changes > in scsi_ioctl.c between 2.4.2 (which builds ok for me) and > 2.4.3-pre4 . > > Doug Gilbert make -C scsi make[2]: Entering directory `/usr/src/linux/drivers/scsi' make -C aic7xxx make[3]: Entering directory `/usr/src/linux/drivers/scsi/aic7xxx' make all_targets make[4]: Entering directory `/usr/src/linux/drivers/scsi/aic7xxx' ld -m elf_i386 -r -o aic7xxx_mod.o aic7xxx_linux.o aic7xxx_linux_pci.o aic7xxx_proc.o aic7770_linux.o aic7xxx.o aic7xxx_pci.o aic7xxx_93cx6.o aic7770.o rm -f aic7xxx_drv.o ld -m elf_i386 -r -o aic7xxx_drv.o aic7xxx_mod.o make[4]: Leaving directory `/usr/src/linux/drivers/scsi/aic7xxx' make[3]: Leaving directory `/usr/src/linux/drivers/scsi/aic7xxx' make all_targets make[3]: Entering directory `/usr/src/linux/drivers/scsi' gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -march=i586-c -o scsi_ioctl.o scsi_ioctl.c scsi_ioctl.c:191: parse error before `Scsi_Ioctl_Command' scsi_ioctl.c:192: warning: function declaration isn't a prototype scsi_ioctl.c: In function `scsi_ioctl_send_command': scsi_ioctl.c:204: `sic' undeclared (first use in this function) scsi_ioctl.c:204: (Each undeclared identifier is reported only once scsi_ioc
Re: Oops 0000 and 0002 on dual PIII 750 2.4.2 SMP platform
On Fri, 16 Mar 2001, Shane Y. Gibson wrote: > Marcelo Tosatti wrote: > > > > Can you please try to reproduce it with the following patch against 2.4.2? > > Marcelo (et al), > > I'll give it a whirl with the patch. Should I also > try setting `nmi_watchdog=0' in lilo.conf, as Andrew > Morton suggests? Andrew's suggestion may avoid the machine from getting frozen (which makes your life easier :)). The oops message will appear with or without the nmi watchdog. > > Additionally, I'll upgrade my version of ksymoops. > Unfortunately, I won't get a chance to test all of > this until Monday; at which time I'll report back to > the group. Ok. We're waiting :) Thanks. - 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/
New ld must have --oformat instead of -oformat ?
Riding the bleeding edge of debian leaves some interesting tastes. Here's one: [..much of build process omitted..] make[1]: Entering directory `/usr/src/linux/arch/i386/boot' gcc -E -D__KERNEL__ -I/usr/src/linux/include -D__BIG_KERNEL__ -traditional -DSVGA_MODE=NORMAL_VGA bootsect.S -o bbootsect.s as -o bbootsect.o bbootsect.s bbootsect.s: Assembler messages: bbootsect.s:253: Warning: indirect lcall without `*' ld -m elf_i386 -Ttext 0x0 -s -oformat binary bbootsect.o -o bbootsect ld: cannot open binary: No such file or directory make[1]: *** [bbootsect] Error 1 make[1]: Leaving directory `/usr/src/linux/arch/i386/boot' make: *** [bzImage] Error 2 The line 'ld: cannot open binary: No such file or directory' is puzzling. I redid the build a few times hoping that it would magically work the next time (the Windows approach), I got over my fear and thought about it. # ld -v GNU ld version 2.11.90.0.1 (with BFD 2.11.90.0.1) # ld --help 2>&1 | grep oformat --oformat TARGETSpecify target of output file The Makefile only has one dash. Changing -oformat to --oformat in arch/i386/boot/Makefile builds the kernel just fine. Did I stumble onto something that is a non-issue or am I just lucky enough to be the first one to trip over it? -- Michael Bacaiella <[EMAIL PROTECTED]> Technical Staff / System Development, New York Connect.Net, Ltd. - 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/
parport not detected
The parallel port is not being detected on my ABIT KT7A KT133 w/ Athlon 900 running 2.2.17 w/ Hendricks IDE patches and RH 6.2. I tried most of the settings in the bios. BIOS options are: 728/IRQ5 378/IRQ7 3BC/IRQ7 with the possible modes: Normal EPP 1.9 or 1.7 ECP DMA 3 or 1 ECP+EPP 1.9 or 1.7 and DMA 3 or 1 Of the above what's optimal? [miallen@nano /etc]$ cat conf.modules alias eth0 3c59x alias char-major-6 parport_pc alias parport_lowlevel parport_pc Also, the module is loading with depmod: [miallen@nano 0]$ for i in /proc/parport/0/*; do echo $i; cat $i; done /proc/parport/0/autoprobe /proc/parport/0/devices /proc/parport/0/hardware base: 0x3bc irq:none dma:none modes: SPP /proc/parport/0/irq none I also tried an options line in modules.conf. I believe it was: options parport_pc io=0x3bc irq=7 That was reflected in /proc but no difference in actually "detecting" the parallel port. I did see the light come on on the printer once though. Also, if I build parpart into the kernel I get nothing but a hard lockup on 'Starting kswapd v 1.5'. Any ideas? Thanks, Mike - 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] Improved version reporting
Hi Andries.
> Neither am I - but, according to comments from RedHat a while back,
> they repackage mount separately because they provide a NEWER version
> of mount than is in the util-linux package. This will ALSO result in
> `mount --version` giving the wrong answer...
> There is no newer version.
Why do RedHat claim there is then?
> In ancient times I came with frequent releases of mount, at a time
> when util-linux was released very infrequently. These years mount
> is part of util-linux, and util-linux is released frequently.
{Shrug} Persuade RedHat of that, not me - they're the ones who release
it separately. Taken directly from RedHat's FTP site, I note that Red
Hat 6.2 includes RPM's for both mount-2.10f-1.i386.rpm and
util-linux-2.10f-7.i386.rpm which, whilst different releases of the
same version, is sufficient to prove your argument false. I can't get
into their 7.0 tree atm to check due to network congestion, so can't
comment on that...
> Unless one can guarantee that the util-linux and mount packages are
> the SAME version, mount can't be guaranteed to report the version of
> the util-linux package installed. RedHat provide a NEWER version of
> mount to util-linux so that guarantee doesnae exist.
> I do not think they do.
{Shrug} Thinking isn't sufficient - check your facts.
> > You are mistaken, as is proved by the reports that contain a kbd
> > line: a grep on linux-kernel for this Februari shows people with
> > Kbd 0.96, 0.99 and 1.02.
>
> {Shrug} Please explain why I was unable to get ver_linux to report a
> When other people can and you cannot, why should I explain your failure?
> Let me just check. A version from 1993:
> % ./loadkeys -h 2>&1 | head -1
> loadkeys version 0.81
>
> A version from 2001:
>
> % ./loadkeys -h 2>&1 | head -1
> loadkeys version 1.06
> Maybe nothing has changed here the past eight years. It just works.
> Perhaps you tried some modified version.
I tried the version that came as part of Red Hat 6.2 as installed
unmodified on the system I'm using. According to the rpm command, I
see...
Q> $ rpm -qf `which loadkeys`
Q> console-tools-19990829-10
Q> $
I've now tried that on FOUR different systems running Red Hat 6.2, the
last of them a fresh install direct from genuine RH 6.2 CD's with NO
changes since, and all four report the same and do exactly the same to
the command in ver_linux so I have to assume that the command in
ver_linux is UNABLE to determine a version number with this release of
Linux.
Best wishes from Riley.
-
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: scsi_scan problem.
"Rafael E. Herrera" wrote: > > sr0: scsi3-mmc drive: 16x/16x xa/form2 changer > sr0: CDROM (ioctl) reports ILLEGAL REQUEST. > sr1: scsi3-mmc drive: 16x/16x xa/form2 changer > sr1: CDROM (ioctl) reports ILLEGAL REQUEST. > sr2: scsi3-mmc drive: 16x/16x xa/form2 changer > sr2: CDROM (ioctl) reports ILLEGAL REQUEST. > sr3: scsi3-mmc drive: 16x/16x xa/form2 changer > sr3: CDROM (ioctl) reports ILLEGAL REQUEST. > sr4: scsi3-mmc drive: 16x/16x xa/form2 changer > sr4: CDROM (ioctl) reports ILLEGAL REQUEST. > sr5: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray > SCSI device sda: 17783240 512-byte hdwr sectors (9105 MB) > sda: sda1 sda2 sda3 sda4 > SCSI device sdb: 8388315 512-byte hdwr sectors (4295 MB) > sdb: sdb1 My guess is, ILLEGAL REQUEST is caused by the sr driver issuing "Mechanism Status" (0xbd) command to the CDROM drives sr0, sr1, sr2, sr3 and sr4. The reason sr driver is issuing this command is because the loading mechanism type field in CD-ROM capabilities page is set to 0x4 (changer). Does the Nakamichi drive put the changer mechanism on a separate LUN, e.g. 1? If so, maybe the "Mechanism Status" commnad should go to LUN 1 but cdrom_read_mech_status() does not set the LUN field in cgc.cmd[1] to any value other than 0. Could this be the reason for ILLEGAL REQUEST? -- Khalid Khalid Aziz Linux Development Laboratory (970)898-9214Hewlett-Packard [EMAIL PROTECTED]Fort Collins, CO - 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: pivot_root & linuxrc problem
In article <[EMAIL PROTECTED]> you wrote: > Aha.. so that's it. I've never been able to get /linuxrc to execute > automagically. I wonder why /linuxrc executes on Art's system, but > not on mine. I can call it whatever I want and it doesn't run unless > I explicitly start it with init=whatever. linuxrc is executed iff: CONFIG_BLK_DEV_INITRD is defined you actually have a initrd mounted /dev/console can be found and opened a executable "/linuxrc" is in the ramdisk Note: initramdisks need to be set up and prepared by your boot loader or with the right structure on your boot media. You also need to have a filesystem on the initrd which the kernel can detect without modules. But kernel does not need to be able to read from the boot device since the image is read by bootloader (e.g. boot-prom or 16bit bios). Greetings Bernd - 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: kernel 2.4.2 network performances
In article <[EMAIL PROTECTED]> you wrote: > Yesterday I discovered that the load I can throw out to network seems to > depend on other activities running on machine. I was able to get > throughput of 33M/s with ATM when machine was idle, while I compiled > kernel at same time, the throughput was 135M/s. - which protocol/application you have used for this - how do you have measured throughput (try wristwatch!) I could think that applications can profit from increased context switches count, especially if there is a handshake network protocol going on. But it could also be some hardware problems. Greetings Bernd - 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: fork and pthreads
> Nitin Sane Wrote: > > On Fri, Mar 16, 2001 at 06:52:26PM +0100, Richard Guenther wrote: > > > Well, using pthreads and forking in them seems to trigger libc > > > bugs (read: SIGSEGvs) here under certain conditions (happens, > > > after I introduced signal handlers and using pthread_sigmask, > > > I think), so hangs should be definitely possible, too... > > > > You must pretty much avoid using signal handlers with pthreads. > > In stead, you need to carefully setup things such that most signals > > are blocked in most threads and a single thread (or selected set > > of threads) does a sigwait for signals of interest. Most good > > pthreads books talk about this issue, as does the DCE documentation. > > I am not using any signals. All the signals are blocked with SIG_IGN > You know, I have been running into that exact same problem, except that I don't fork at all. I start up my process and nearly immediately try and spawn a few threads. The calling thread blocks indefinately in a __sigsuspend(), but is apparently delivered an unknown signal. The spawned thread executes normally. It appears to be fixed when I compile with -D_REENTRANT, but I am not certain... Laramie - 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: scsi_scan problem.
"Rafael E. Herrera" wrote: > > I applied the first hunk to version 2.4.3-pre4, as by email with Doug. > The output for the scsi devices follows and is identical with and > without the patch. Thank you Rafael. This is what I suspected. I'm not sure when we starting considering devices with a peripheral qualifier of 1 as being valid, but I suspect it happened when the scsi_scan.c code was separated out of scsi.c. In any case, I'm pretty positive that it is the wrong thing to do. This report at least alleviates one of my fears about broken device possibilities and starts to confirm my position. > Maybe someone can explain the meaning of the illegal > requests at the end. Nevertheless, I can use the drive fine. As to the illegal request messages, I'm not sure what those are about ;-) -- Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford Please check my web site for aic7xxx updates/answers before e-mailing me about problems - 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: scsi_scan problem.
I applied the first hunk to version 2.4.3-pre4, as by email with Doug. The output for the scsi devices follows and is identical with and without the patch. Maybe someone can explain the meaning of the illegal requests at the end. Nevertheless, I can use the drive fine. Loading module aic7xxx_old ... Using /lib/modules/2.4.3-pre4/kernel/drivers/scsi/aic7xxx_old.o (scsi0) found at PCI 0/14/1 (scsi0) Wide Channel B, SCSI ID=7, 32/255 SCBs (scsi0) Downloading sequencer code... 383 instructions downloaded (scsi1) found at PCI 0/14/0 (scsi1) Wide Channel A, SCSI ID=7, 32/255 SCBs (scsi1) Downloading sequencer code... 383 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 (scsi0:0:0:0) Synchronous at 40.0 Mbyte/sec, offset 8. Vendor: SEAGATE Model: ST39173LW Rev: 6246 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 0, id 0, lun 0 (scsi1:0:2:0) Synchronous at 10.0 Mbyte/sec, offset 15. Vendor: SEAGATE Model: ST15150N Rev: 4611 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sdb at scsi1, channel 0, id 2, lun 0 (scsi1:0:4:0) Synchronous at 10.0 Mbyte/sec, offset 15. Vendor: NAKAMICH Model: MJ-5.16S Rev: 1.02 Type: CD-ROM ANSI SCSI revision: 02 Detected scsi CD-ROM sr0 at scsi1, channel 0, id 4, lun 0 Vendor: NAKAMICH Model: MJ-5.16S Rev: 1.02 Type: CD-ROM ANSI SCSI revision: 02 Detected scsi CD-ROM sr1 at scsi1, channel 0, id 4, lun 1 Vendor: NAKAMICH Model: MJ-5.16S Rev: 1.02 Type: CD-ROM ANSI SCSI revision: 02 Detected scsi CD-ROM sr2 at scsi1, channel 0, id 4, lun 2 Vendor: NAKAMICH Model: MJ-5.16S Rev: 1.02 Type: CD-ROM ANSI SCSI revision: 02 Detected scsi CD-ROM sr3 at scsi1, channel 0, id 4, lun 3 Vendor: NAKAMICH Model: MJ-5.16S Rev: 1.02 Type: CD-ROM ANSI SCSI revision: 02 Detected scsi CD-ROM sr4 at scsi1, channel 0, id 4, lun 4 (scsi1:0:5:0) Synchronous at 10.0 Mbyte/sec, offset 15. Vendor: TEAC Model: CD-R56S4 Rev: 1.0P Type: CD-ROM ANSI SCSI revision: 02 Detected scsi CD-ROM sr5 at scsi1, channel 0, id 5, lun 0 sr0: scsi3-mmc drive: 16x/16x xa/form2 changer sr0: CDROM (ioctl) reports ILLEGAL REQUEST. sr1: scsi3-mmc drive: 16x/16x xa/form2 changer sr1: CDROM (ioctl) reports ILLEGAL REQUEST. sr2: scsi3-mmc drive: 16x/16x xa/form2 changer sr2: CDROM (ioctl) reports ILLEGAL REQUEST. sr3: scsi3-mmc drive: 16x/16x xa/form2 changer sr3: CDROM (ioctl) reports ILLEGAL REQUEST. sr4: scsi3-mmc drive: 16x/16x xa/form2 changer sr4: CDROM (ioctl) reports ILLEGAL REQUEST. sr5: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray SCSI device sda: 17783240 512-byte hdwr sectors (9105 MB) sda: sda1 sda2 sda3 sda4 SCSI device sdb: 8388315 512-byte hdwr sectors (4295 MB) sdb: sdb1 -- Rafael - 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/
X freeze/ kernel 4.2/ gnome/ alpha LX164
Does this belong elsewhere? outline follows, details available. I have a series of log entries that look like this: got res[:] for resource X of One device was the 21140 chip on my ethernet card. A few were for the matrox video card. Symptoms were frozen keyboard, but able to get in fro 2d system. X was very busy (95% of CPU). Killed softare piece by piece with no change. Killed gdm. No change. Runlevel change to 5 got me into gnome, switching back to 3 got back the frozen keyboard. Reboot required. mhansel [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 against 2.4.2: TTY hangup on PPP channel corrupts kernel memory
Linus:
This one was tough to find. I think I triggered it maybe four times
over the space of six months and almost chalked it up to an electrical
problem with the modem.
If there's a hangup in the TTY layer on an async PPP channel,
do_tty_hangup shuts down the PPP line discipline, and, in ppp_async.c,
the function ppp_asynctty_close unregisteres the channel. In
ppp_generic.c, ppp_unregister_channel merrily wakes up the rwait
queue, then proceeds to destroy the channel, freeing the "struct
channel" which contains the "struct ppp_file" that contains the
"wait_queue_head_t rwait". When the waiting process wakes up, it
removes itself from the wait queue, modifying freed memory.
(In my case, it turns out that the "struct channel" in ppp_generic.c
and "struct shmid_kernel" are both in the size-128 slab cache. My
desktop pager uses the X SHM extension to snapshot the desktop and
does many SHM allocations per second. In the occasional case that the
allocation beats the rwaiting process, a modem hangup sends the X
server spinning on a random piece of memory way down in
"valid_swaphandles", and the other CPU locks up in some unrelated
place waiting on the kernel lock.)
A patch against 2.4.2 follows. I've overloaded the "refcnt" in
"struct ppp_file" to also keep track of rwaiters. The last refcnt
user destroys the channel and decreases the module use count. I've
tested this with printks in all the right places, and it seems to fix
the problem correctly.
I don't use any other PPP drivers besides async, but it looks like the
same bug exists (and will be fixed by this patch) in ppp_synctty.c.
The FILEVERSION at the top of ppp_generic may need to be fixed, but
Thanks.
Kevin <[EMAIL PROTECTED]>
* * *
--- linux-2.4.2/drivers/net/ppp_generic.c Sun Mar 4 20:09:19 2001
+++ linux-2.4.2-local/drivers/net/ppp_generic.c Fri Mar 16 14:50:28 2001
@@ -72,7 +72,7 @@
struct sk_buff_head xq; /* pppd transmit queue */
struct sk_buff_head rq; /* receive queue for pppd */
wait_queue_head_t rwait;/* for poll on reading /dev/ppp */
- atomic_trefcnt; /* # refs (incl /dev/ppp attached) */
+ atomic_trefcnt; /* # refs (attaches and rwaiters) */
int hdrlen; /* space to leave for headers */
struct list_head list; /* link in all_* list */
int index; /* interface unit / channel number */
@@ -316,6 +316,28 @@
return 0;
}
+/*
+ * For ppp_async, a (true) hangup in the TTY layer will shut down the
+ * current line discipline, unregistering the channel, so...
+ *
+ * We must ppp_file_acquire before waiting on rwait to keep the
+ * channel around, then ppp_file_release after waiting to release
+ * resources if we're the last user.
+ */
+#define ppp_file_acquire(pf) atomic_inc(&(pf)->refcnt)
+static void ppp_file_release(struct ppp_file *pf) {
+ if (atomic_dec_and_test(&pf->refcnt)) {
+ switch (pf->kind) {
+ case INTERFACE:
+ ppp_destroy_interface(PF_TO_PPP(pf));
+ break;
+ case CHANNEL:
+ ppp_destroy_channel(PF_TO_CHANNEL(pf));
+ break;
+ }
+ }
+}
+
static int ppp_release(struct inode *inode, struct file *file)
{
struct ppp_file *pf = (struct ppp_file *) file->private_data;
@@ -323,16 +345,7 @@
lock_kernel();
if (pf != 0) {
file->private_data = 0;
- if (atomic_dec_and_test(&pf->refcnt)) {
- switch (pf->kind) {
- case INTERFACE:
- ppp_destroy_interface(PF_TO_PPP(pf));
- break;
- case CHANNEL:
- ppp_destroy_channel(PF_TO_CHANNEL(pf));
- break;
- }
- }
+ ppp_file_release(pf);
}
unlock_kernel();
return 0;
@@ -357,6 +370,7 @@
if (pf == 0)
goto out; /* not currently attached */
+ ppp_file_acquire(pf);
add_wait_queue(&pf->rwait, &wait);
current->state = TASK_INTERRUPTIBLE;
for (;;) {
@@ -376,6 +390,7 @@
}
current->state = TASK_RUNNING;
remove_wait_queue(&pf->rwait, &wait);
+ ppp_file_release(pf);
if (skb == 0)
goto out;
@@ -448,6 +463,7 @@
if (pf == 0)
return 0;
+ ppp_file_acquire(pf);
poll_wait(file, &pf->rwait, wait);
mask = POLLOUT | POLLWRNORM;
if (skb_peek(&pf->rq) != 0)
@@ -457,6 +473,7 @@
if (pch->chan == 0)
mask |= POLLHUP;
}
+ ppp_file_release(pf);
return mask;
}
@@ -1788,9 +1805,12 @@
spin_lock_bh(&all_
Re: UDP stop transmitting packets!!!
>In fact, the current choice is optimal. If the problem is that we are >being hit with too many packets too quickly, the most desirable course >of action is the one which requires the least amount of computing >power. Doing nothing to the receive queue is better than trying to >"dequeue" some of the packets there to allow the new one to be added. A study by Greg Finn <[EMAIL PROTECTED]> determined that randomly dropping packets in a congested queue may be preferable to dropping only newly received packets. Dropping only newly-arrived packets can be suboptimal, depending upon the details of how your packets are generated, of course. YMMV. "A Connectionless Congestion Control Algorithm" Finn, Greg ACM Computer Communication Review, Vol. 19, No. 5., pp. 12-31,Oct. 1989. The way I view this result is that each packet is part of a flow (true even for most UDP packets). Dropping a packet penalizes the flow. All packets in a queue contribute to the queue's congestion, not simply the most recently-arrived packet. Dropping a random packet in the queue distributes the penalty among the flows in the queue. Over the statistical average, this is more optimal than dropping the latest packet. Craig Milo Rogers - 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: UDP stop transmitting packets!!!
Mathieu Giguere (LMC) writes: > Thanks for your answer. > We will have a patch internally to handle this protection. I would like to clarify my statements: > > -Original Message- > > From: David S. Miller [SMTP:[EMAIL PROTECTED]] > > Subject: RE: UDP stop transmitting packets!!! > > > > If you kill the application, the queue is emptied and tossed > > by the kernel. This should be "If you close the socket" then the queue will be drained and free'd by the kernel. Killing the application is one way to get the socket closed. Later, David S. Miller [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: UDP stop transmitting packets!!!
Mathieu Giguere (LMC) writes: > Ok fine to live with that for security reason, but the socket will be dead > for ever! (the only way to remove it is to reboot the machine) If you kill the application, the queue is emptied and tossed by the kernel. Later, David S. Miller [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: UDP stop transmitting packets!!!
Ok fine to live with that for security reason, but the socket will be dead for ever! (the only way to remove it is to reboot the machine) Can be possible to have a timer when the queue is full (something like 1 minute) to wait before dequeueing all of it and retrying to continue to process request? Because we need to process a large amount of UDP packets and this anoying trick come break the machine quickly (like 12 minutes). /mathieu > -Original Message- > From: David S. Miller [SMTP:[EMAIL PROTECTED]] > Sent: Friday, March 16, 2001 4:29 PM > To: Mathieu Giguere (LMC) > Cc: '[EMAIL PROTECTED]'; Claude LeFrancois (LMC) > Subject: Re: UDP stop transmitting packets!!! > > > Mathieu Giguere (LMC) writes: > > The problem with the previous code, when the queue become full (for any > > reason) you don't try to de-queue packet form it. > > That is right, UDP is an unreliable transport so it doesn't > matter which packets we drop in such a case. > > In fact, the current choice is optimal. If the problem is that we are > being hit with too many packets too quickly, the most desirable course > of action is the one which requires the least amount of computing > power. Doing nothing to the receive queue is better than trying to > "dequeue" some of the packets there to allow the new one to be added. > > Later, > David S. Miller > [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: UDP stop transmitting packets!!!
Thanks for your answer. We will have a patch internally to handle this protection. /mathieu > -Original Message- > From: David S. Miller [SMTP:[EMAIL PROTECTED]] > Sent: Friday, March 16, 2001 4:46 PM > To: Mathieu Giguere (LMC) > Cc: '[EMAIL PROTECTED]'; Claude LeFrancois (LMC) > Subject: RE: UDP stop transmitting packets!!! > > > Mathieu Giguere (LMC) writes: > > Ok fine to live with that for security reason, but the socket will be > dead > > for ever! (the only way to remove it is to reboot the machine) > > If you kill the application, the queue is emptied and tossed > by the kernel. > > Later, > David S. Miller > [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: UDP stop transmitting packets!!!
Mathieu Giguere (LMC) writes: > The problem with the previous code, when the queue become full (for any > reason) you don't try to de-queue packet form it. That is right, UDP is an unreliable transport so it doesn't matter which packets we drop in such a case. In fact, the current choice is optimal. If the problem is that we are being hit with too many packets too quickly, the most desirable course of action is the one which requires the least amount of computing power. Doing nothing to the receive queue is better than trying to "dequeue" some of the packets there to allow the new one to be added. Later, David S. Miller [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/
UDP stop transmitting packets!!!
Hi all,
I will try to explain your the situation of test:
kernel 2.2.17 (yeah an old one but the goal of this comments is for future
kernel to remove this littel bug)
You need to stress your network (4 pings in fload mode with packet size of
125 bytes should do the thing)
And you pass some traffic on a UDP socket port something.
What append if you look in /proc/net/udp
you will see the rx_queue column going up (no problem with that)
but when you reach the maximum queue size, all packet to be drop.
you can see why in the 2 function here:
net/ipv4/udp.c
static int udp_queue_rcv_skb(struct sock * sk, struct sk_buff *skb)
{
/*
* Charge it to the socket, dropping if the queue is full.
*/
#if defined(CONFIG_FILTER) && defined(CONFIG_UDP_DELAY_CSUM)
if (sk->filter && skb->ip_summed != CHECKSUM_UNNECESSARY) {
if ((unsigned short)csum_fold(csum_partial(skb->h.raw,
skb->len, skb->csum))) {
udp_statistics.UdpInErrors++;
ip_statistics.IpInDiscards++;
ip_statistics.IpInDelivers--;
kfree_skb(skb);
return -1;
}
skb->ip_summed = CHECKSUM_UNNECESSARY;
}
#endif
// When you try to queue the message it will faild because the queue is
full
if (sock_queue_rcv_skb(sk,skb)<0) {
udp_statistics.UdpInErrors++;
ip_statistics.IpInDiscards++;
ip_statistics.IpInDelivers--;
kfree_skb(skb);
return -1;
}
udp_statistics.UdpInDatagrams++;
return 0;
}
include/net/sock.h
extern __inline__ int sock_queue_rcv_skb(struct sock *sk, struct sk_buff
*skb)
{
#ifdef CONFIG_FILTER
struct sk_filter *filter;
#endif
/* Cast skb->rcvbuf to unsigned... It's pointless, but reduces
number of warnings when compiling with -W --ANK
*/
//you try to check if you have enough space and if not you discard the
packet (ok fine)
if (atomic_read(&sk->rmem_alloc) + skb->truesize >=
(unsigned)sk->rcvbuf)
return -ENOMEM;
#ifdef CONFIG_FILTER
if ((filter = sk->filter) != NULL && sk_filter(skb, filter))
return -EPERM; /* Toss packet */
#endif /* CONFIG_FILTER */
skb_set_owner_r(skb, sk);
skb_queue_tail(&sk->receive_queue, skb);
if (!sk->dead)
sk->data_ready(sk,skb->len);
return 0;
}
The problem with the previous code, when the queue become full (for any
reason) you don't try to de-queue packet form it.
So no packet can be process and all are reject by udp
(udp_statistics.UdpInErrors++;)
A possible solution can be something like that:
try to de-queue packets when the queue is full! (a little protection here)
if (atomic_read(&sk->rmem_alloc) + skb->truesize >=
(unsigned)sk->rcvbuf) {
if (!sk->dead) sk->data_ready(sk,0);
return -ENOMEM;
}
/mathieu
-
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] ip_dynaddr re-enable
Hello,
about one or two months ago, I had the problem that
/proc/sys/net/ipv4/ip_dynaddr did not work. I analyzed the
problem and somehow came to a solution which I have
forgotten. But a patch which solved the problem against
2.4.1 which also works for 2.4.2-pre4 remained. Here it is.
Xuân.
--- linux/net/ipv4/tcp_ipv4.c.orig Tue Jan 30 11:37:56 2001
+++ linux/net/ipv4/tcp_ipv4.c Tue Jan 30 13:31:14 2001
@@ -1774,6 +1774,11 @@
u32 daddr;
int err;
+ if (sysctl_ip_dynaddr > 2) {
+ printk(KERN_INFO "tcp_v4_rebuild_header(): sysctl_ip_dynaddr=%d,
+sk->userlocks=0x%x, rt==0x%x, src=%d.%d.%d.%d, sk->state=%d,sk->userlocks=0x%x.\n",
+ sysctl_ip_dynaddr,
+sk->userlocks,rt,NIPQUAD(sk->saddr),sk->state,sk->userlocks);
+ }
+
/* Route is OK, nothing to do. */
if (rt != NULL)
return 0;
@@ -1783,9 +1788,26 @@
if(sk->protinfo.af_inet.opt && sk->protinfo.af_inet.opt->srr)
daddr = sk->protinfo.af_inet.opt->faddr;
+ if ((sysctl_ip_dynaddr) && (sk->state == TCP_SYN_SENT) && (!(sk->userlocks &
+SOCK_BINDADDR_LOCK)) ) {
+ err = tcp_v4_reselect_saddr(sk);
+
+ if (sysctl_ip_dynaddr > 2) {
+ printk(KERN_INFO "tcp_v4_rebuild_header():
+tcp_v4_reselect_saddr(sk)=%d.\n",err);
+ }
+
+ if (err!=0) {
+ sk->err_soft=-err;
+ /* sk->error_report(sk); */
+ }
+ }
+
err = ip_route_output(&rt, daddr, sk->saddr,
RT_TOS(sk->protinfo.af_inet.tos) | RTO_CONN |
sk->localroute,
sk->bound_dev_if);
+ if (sysctl_ip_dynaddr > 2) {
+ printk(KERN_INFO "tcp_v4_rebuild_header(): err=%d.\n",
+ err);
+ }
if (!err) {
__sk_dst_set(sk, &rt->u.dst);
/* sk->route_caps = rt->u.dst.dev->features; */
Locking question (was: [CHECKER] 9 potential copy_*_user bugs in2.4.1)
On Thu, 15 Mar 2001, Dawson Engler wrote: > 2. And, unrelated: given the current locking discipline, is > it bad to hold any type of lock (not just a spin lock) when you > call a potentially blocking function? (It at least seems bad > for performance, since you'll hold the lock for milliseconds.) In general, yes. The lock may be held for much longer than milliseconds if the potentially blocking function is waiting for I/O from a network, or a terminal, potentially causing all threads to block on the lock until someone presses a key, in this extreme example. If the lock is a spinlock, then complete deadlock can occur. You're probably aware that semaphores are used both as blocking mutex locks, where the down (lock) and up (unlock) calls are made by the same thread to protect critical data, and as a synchronization mechanism, where the down and up calls are made by different threads. The former use is a "lock", while the latter down() use is a "potentially blocking function" in terms of your question. I don't know how easy it would be for your analysis tools to distinguish between them. 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: [PATCH]: Only one memory zone for sparc64
Hi, On Thu, Mar 15, 2001 at 07:13:52PM +1100, Anton Blanchard wrote: > > On sparc64 we dont care about the different memory zones and iterating > through them all over the place only serves to waste CPU. I suspect this > would be the case with some other architectures but for the moment I > have just enabled it for sparc64. > > With this patch I get close to a 1% improvement in dbench on the dual > ultra60. I'd be surprised if dbench was anything other than disk-bound on most systems. On any of my machines, the standard error of a single dbench run is *way* larger than 1%, and I'd expect to have to run the benchmark a dozen times to get a confidence interval small enough to detect a 1% performance change: are your runs repeatable enough to be this sensitive to the effect of the allocator? Cheers, Stephen - 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: changing mm->mmap_sem (was: Re: system call for process information?)
Hi, On Fri, Mar 16, 2001 at 08:50:25AM -0300, Rik van Riel wrote: > On Fri, 16 Mar 2001, Stephen C. Tweedie wrote: > > > > Write locks would be used in the code where we actually want > > > to change the VMA list and page faults would use an extra lock > > > to protect against each other (possibly a per-pagetable lock > > > > Why do we need another lock? The critical section where we do the > > final update on the pte _already_ takes the page table spinlock to > > avoid races against the swapper. > > The problem is that mmap_sem seems to be protecting the list > of VMAs, so taking _only_ the page_table_lock could let a VMA > change under us while a page fault is underway ... Right, I'm not suggesting removing that: making the mmap_sem read/write is fine, but yes, we still need that semaphore. But as for the "page faults would use an extra lock to protect against each other" bit --- we already have another lock, the page table lock, which can be used in this way, so ANOTHER lock should be unnecessary. --Stephen - 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.2/2.4.3-pre4 IDE DMA problems w/ PDC20267+IBM DTLA
Because you disabled the PIIX3 the PDC20267 stole the interrupt 14.
That is a special interrupt for legacy.
test243-pdc20267-dma-module
What he heck is dma-module?
That is not allowed, what have you modified?
If you want to to help I require the entire effected source and
corresponding extras, period.
On Fri, 16 Mar 2001, [iso-8859-1] Henrik Størner wrote:
> I am struggling to get an IBM DTLA-307045 drive attached to a
> promise pdc20267 controller to work in DMA mode. Right now,
> whenever I enable a DMA mode, I get timeouts when accessing
> the drive.
>
> I am using an 80-pin cable, that came with the Promise controller.
>
> Mar 16 20:57:43 ask kernel: Uniform Multi-Platform E-IDE driver Revision: 6.31
> Mar 16 20:57:43 ask kernel: ide: Assuming 33MHz system bus speed for PIO modes;
>override with idebus=xx
> Mar 16 20:57:43 ask kernel: PDC20267: IDE controller on PCI bus 00 dev 30
> Mar 16 20:57:43 ask kernel: PDC20267: chipset revision 2
> Mar 16 20:57:43 ask kernel: PDC20267: not 100%% native mode: will probe irqs later
> Mar 16 20:57:43 ask kernel: PDC20267: ROM enabled at 0x8000
> Mar 16 20:57:43 ask kernel: PDC20267: (U)DMA Burst Bit ENABLED Primary PCI Mode
>Secondary PCI Mode.
> Mar 16 20:57:43 ask kernel: ide2: BM-DMA at 0x8040-0x8047, BIOS settings:
>hde:DMA, hdf:pio
> Mar 16 20:57:43 ask kernel: ide3: BM-DMA at 0x8048-0x804f, BIOS settings:
>hdg:pio, hdh:pio
> Mar 16 20:57:43 ask kernel: PIIX3: IDE controller on PCI bus 00 dev 61
> Mar 16 20:57:43 ask kernel: PIIX3: chipset revision 0
> Mar 16 20:57:43 ask kernel: PIIX3: not 100%% native mode: will probe irqs later
> Mar 16 20:57:43 ask kernel: PIIX3: neither IDE port enabled (BIOS)
> Mar 16 20:58:23 ask kernel: hde: IBM-DTLA-307045, ATA DISK drive
> Mar 16 20:58:23 ask kernel: ide2 at 0x8000-0x8007,0x800a on irq 14
> Mar 16 20:59:00 ask kernel: A Register SYNC_IN ERRDY_EN IORDY_EN PREFETCH_EN PA0
>PIO(A) = 1
> Mar 16 20:59:00 ask kernel: AP 0001
> Mar 16 20:59:00 ask kernel: B Register MB0 DMA(B) = 1 PB2 PIO(B) = 4
> Mar 16 20:59:00 ask kernel: BP 00100100
> Mar 16 20:59:00 ask kernel: C Register IORDYp MC0 DMA(C) = 1
> Mar 16 20:59:00 ask kernel: CP 0101
> Mar 16 20:59:00 ask kernel: D Register
> Mar 16 20:59:00 ask kernel: DP
> Mar 16 20:59:00 ask kernel: hde: UDMA 5 drive0 0x004124f1 0x004124f1
> Mar 16 20:59:00 ask kernel: hde: 90069840 sectors (46116 MB) w/1916KiB Cache,
>CHS=89355/16/63, UDMA(100)
> Mar 16 20:59:20 ask kernel: hde:hde: timeout waiting for DMA
> Mar 16 20:59:20 ask kernel: ide_dmaproc: chipset supported ide_dma_timeout func
>only: 14
> Mar 16 20:59:20 ask kernel: hde: irq timeout: status=0x50 { DriveReady SeekComplete }
>
> Any ideas on how to improve the state of things ? The drive works
> in non-DMA mode, but the performance is pretty poor (~ 5 MB/sec
> on a 'hdparm -t') - I would like to make it somewhat snappier.
>
> The system is a Pentium/166 with 64 MB RAM, and a built-in PIIX3
> chipset. The IBM drive is the only IDE drive in the system, and I
> have tried with both the built-in IDE controller disabled and
> enabled. Here's the full dmesg:
>
> Linux version 2.4.3-pre4 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66
>19990314/Linux (egcs-1.1.2 release)) #19 Fri Mar 16 20:44:30 CET 2001
> BIOS-provided physical RAM map:
> BIOS-e820: 0009e800 @ (usable)
> BIOS-e820: 1800 @ 0009e800 (reserved)
> BIOS-e820: 0001 @ 000f (reserved)
> BIOS-e820: 03f0 @ 0010 (usable)
> BIOS-e820: 0004 @ fffc (reserved)
> On node 0 totalpages: 16384
> zone(0): 4096 pages.
> zone(1): 12288 pages.
> zone(2): 0 pages.
> Kernel command line: BOOT_IMAGE=test3 ro root=805
>BOOT_FILE=/boot/test243-pdc20267-dma-module
> Initializing CPU#0
> Detected 166.588 MHz processor.
> Console: colour VGA+ 80x25
> Calibrating delay loop... 332.59 BogoMIPS
> Memory: 62184k/65536k available (1079k kernel code, 2960k reserved, 389k data, 188k
>init, 0k highmem)
> Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes)
> Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
> Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
> Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
> CPU: Before vendor init, caps: 01bf , vendor = 0
> Intel Pentium with F0 0F bug - workaround enabled.
> CPU: After vendor init, caps: 01bf
> CPU: After generic, caps: 01bf
> CPU: Common caps: 01bf
> CPU: Intel Pentium 75 - 200 stepping 0c
> Checking 'hlt' instruction... OK.
> POSIX conformance testing by UNIFIX
> PCI: PCI BIOS revision 2.10 entry at 0xfd83e, last bus=0
> PCI: Using configuration type 1
> PCI: Probing PCI hardware
> Limiting direct PCI/PCI transfers.
> Activating ISA DMA hang workarounds.
> Linux NET4.0 for Linux 2.4
>
2.4.2/2.4.3-pre4 IDE DMA problems w/ PDC20267+IBM DTLA
I am struggling to get an IBM DTLA-307045 drive attached to a
promise pdc20267 controller to work in DMA mode. Right now,
whenever I enable a DMA mode, I get timeouts when accessing
the drive.
I am using an 80-pin cable, that came with the Promise controller.
Mar 16 20:57:43 ask kernel: Uniform Multi-Platform E-IDE driver Revision: 6.31
Mar 16 20:57:43 ask kernel: ide: Assuming 33MHz system bus speed for PIO modes;
override with idebus=xx
Mar 16 20:57:43 ask kernel: PDC20267: IDE controller on PCI bus 00 dev 30
Mar 16 20:57:43 ask kernel: PDC20267: chipset revision 2
Mar 16 20:57:43 ask kernel: PDC20267: not 100%% native mode: will probe irqs later
Mar 16 20:57:43 ask kernel: PDC20267: ROM enabled at 0x8000
Mar 16 20:57:43 ask kernel: PDC20267: (U)DMA Burst Bit ENABLED Primary PCI Mode
Secondary PCI Mode.
Mar 16 20:57:43 ask kernel: ide2: BM-DMA at 0x8040-0x8047, BIOS settings: hde:DMA,
hdf:pio
Mar 16 20:57:43 ask kernel: ide3: BM-DMA at 0x8048-0x804f, BIOS settings: hdg:pio,
hdh:pio
Mar 16 20:57:43 ask kernel: PIIX3: IDE controller on PCI bus 00 dev 61
Mar 16 20:57:43 ask kernel: PIIX3: chipset revision 0
Mar 16 20:57:43 ask kernel: PIIX3: not 100%% native mode: will probe irqs later
Mar 16 20:57:43 ask kernel: PIIX3: neither IDE port enabled (BIOS)
Mar 16 20:58:23 ask kernel: hde: IBM-DTLA-307045, ATA DISK drive
Mar 16 20:58:23 ask kernel: ide2 at 0x8000-0x8007,0x800a on irq 14
Mar 16 20:59:00 ask kernel: A Register SYNC_IN ERRDY_EN IORDY_EN PREFETCH_EN PA0
PIO(A) = 1
Mar 16 20:59:00 ask kernel: AP 0001
Mar 16 20:59:00 ask kernel: B Register MB0 DMA(B) = 1 PB2 PIO(B) = 4
Mar 16 20:59:00 ask kernel: BP 00100100
Mar 16 20:59:00 ask kernel: C Register IORDYp MC0 DMA(C) = 1
Mar 16 20:59:00 ask kernel: CP 0101
Mar 16 20:59:00 ask kernel: D Register
Mar 16 20:59:00 ask kernel: DP
Mar 16 20:59:00 ask kernel: hde: UDMA 5 drive0 0x004124f1 0x004124f1
Mar 16 20:59:00 ask kernel: hde: 90069840 sectors (46116 MB) w/1916KiB Cache,
CHS=89355/16/63, UDMA(100)
Mar 16 20:59:20 ask kernel: hde:hde: timeout waiting for DMA
Mar 16 20:59:20 ask kernel: ide_dmaproc: chipset supported ide_dma_timeout func only:
14
Mar 16 20:59:20 ask kernel: hde: irq timeout: status=0x50 { DriveReady SeekComplete }
Any ideas on how to improve the state of things ? The drive works
in non-DMA mode, but the performance is pretty poor (~ 5 MB/sec
on a 'hdparm -t') - I would like to make it somewhat snappier.
The system is a Pentium/166 with 64 MB RAM, and a built-in PIIX3
chipset. The IBM drive is the only IDE drive in the system, and I
have tried with both the built-in IDE controller disabled and
enabled. Here's the full dmesg:
Linux version 2.4.3-pre4 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release)) #19 Fri Mar 16 20:44:30 CET 2001
BIOS-provided physical RAM map:
BIOS-e820: 0009e800 @ (usable)
BIOS-e820: 1800 @ 0009e800 (reserved)
BIOS-e820: 0001 @ 000f (reserved)
BIOS-e820: 03f0 @ 0010 (usable)
BIOS-e820: 0004 @ fffc (reserved)
On node 0 totalpages: 16384
zone(0): 4096 pages.
zone(1): 12288 pages.
zone(2): 0 pages.
Kernel command line: BOOT_IMAGE=test3 ro root=805
BOOT_FILE=/boot/test243-pdc20267-dma-module
Initializing CPU#0
Detected 166.588 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 332.59 BogoMIPS
Memory: 62184k/65536k available (1079k kernel code, 2960k reserved, 389k data, 188k
init, 0k highmem)
Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
CPU: Before vendor init, caps: 01bf , vendor = 0
Intel Pentium with F0 0F bug - workaround enabled.
CPU: After vendor init, caps: 01bf
CPU: After generic, caps: 01bf
CPU: Common caps: 01bf
CPU: Intel Pentium 75 - 200 stepping 0c
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
PCI: PCI BIOS revision 2.10 entry at 0xfd83e, last bus=0
PCI: Using configuration type 1
PCI: Probing PCI hardware
Limiting direct PCI/PCI transfers.
Activating ISA DMA hang workarounds.
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
Detected PS/2 Mouse Port.
pty: 256 Unix98 ptys configured
block: queued sectors max/low 41248kB/13749kB, 128 slots per queue
Floppy drive(s): fd0 is 1.44M
FDC 0 is a National Semiconductor PC87306
Real Time Clock Driver v1.10d
eepro100.c:v1.09j-t 9/29/99 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html
eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin
<[EMAIL PROTECTED]> and others
eth0: Intel Corporation 82557
Re: scsi_scan problem.
Doug, could you check how this patch works if you have the qla2x00 installed in an
Alpha box? I'm hoping this is part of the source of my problems, but I'm not
positive. (I'd do it, but my system is running benchmarks for the next several
days.) Thanks!
- Pete
Doug Ledford wrote:
> Ishikawa wrote:
> >
> > Hi,
> >
> > I have an "old" Nakamichi CD changer.
> > ("old" might be important consideration here. )
> >
> > Should I test the patch submitted and report what I found ?
> > (Or maybe I don't have to bother at this stage at all
> > and simply wait for the 2.5 development and debugging cycle?)
>
> It would still be helpful because this problem has to be fixed before 2.5.
> The only question is whether to fix it with a simple patch such as I just
> submitted, or a more complex patch that uses REPORT LUNs. Part of that answer
> is how my simple patch works on your device.
>
> --
>
> Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
> Please check my web site for aic7xxx updates/answers before
> e-mailing me about problems
> -
> 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: IDE UDMA on a CMD-648 Chip
On Fri, 16 Mar 2001, John Heil wrote: > I've acquired a UDMA66 capable IDE card with a CMD-648 chip, > which is supposed to provide me with ide2 and ide3. > ide2 is empty and ide3 has a writeable cdrom and an IDE zip > drive on it. > However, it indicates that since it... > 'Can't find a UDMA66 capable device' > it is 'Disabling the UDMA66 bios'. Ok, the devices you mentioned above are not UDMA66 capable, so the controller dropped to UDMA33 capabilities. Nothing wrong there. > I'll be upgrading this machine to 2.4.n-whatever in about 3 wks but... > ...I'd like to get the 2 devices operational on this or > some other 2.2.x, before that, if I can. cmd648 seems to be supported in in 2.4. (drivers/ide/cmd64x.c) This hasn't been backported to 2.2.x. So either backport it, or upgrade to 2.4 > I am hoping to circumvent the bios. I assume it will involve some > measure of IDE initialization which I don't mind coding if > it does not exist yet. Well the hard part has already been done for you :) regards, Dave. -- | Dave Jones.http://www.suse.de/~davej | SuSE Labs - 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/
VIA686B + 2.2.18 (was: VIA686A chipset crash under 2.4.2-ac20)
On Fri, Mar 16, 2001 at 10:42:26AM -0800, Andre Hedrick wrote: > > Okay not to worry, I now have a my hands on a VIA 686B and will look > at the changes that happened to the VIA686A > > Have you run 2.2.18 plus my patches off kernel.org? Hi Andre, I'm running 2.2.18 on VIA686B (ABit VP6). Some time ago, you mentioned that you got ~80Mb/s from 'hdparm -t /dev/hda'. Please tell us how? Which hdparm/kernel options did you enable? :wq --William Park, Open Geometry Consulting, Linux/Python, 8 CPUs. - 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: VIA686A chipset crash under 2.4.2-ac20
Yes you should try because there is a fundamental difference in design of VIA between 2.2.x + patches and 2.4.x On Fri, 16 Mar 2001, Kirill Kozmin wrote: > Andre Hedrick wrote: > > > Okay not to worry, I now have a my hands on a VIA 686B and will look at > > the changes that happened to the VIA686A > > > > Have you run 2.2.18 plus my patches off kernel.org? > > > > No, I didn't run it. Whould I? > > -- > ** > > Sincerely yours > Kirill Kozmin > > E-mail:[EMAIL PROTECTED] > > Homepage:www.ludd.luth.se/~kozkir-8/ > > ** > > Andre Hedrick Linux ATA Development ASL Kernel Development - ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035Web: www.aslab.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/
gcc-2.95.3 release
Hi, gcc-2.95.3 has just been released. Could it be used for kernel compilation, or still better stick with gcc-2.91.66 for "absolute stability"? Thanks, Art. - 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: IDE UDMA on a CMD-648 Chip
Unless you have patches for 2.2 kernels most addon hosts will not be seen. On Fri, 16 Mar 2001, John Heil wrote: > > I've acquired a UDMA66 capable IDE card with a CMD-648 chip, > which is supposed to provide me with ide2 and ide3. > > ide2 is empty and ide3 has a writeable cdrom and an IDE zip > drive on it. > > At boot up, the card's bios scan recognizes the cdrom and zip > as master and slave on its secondary ide i/f, which is correct. > > However, it indicates that since it... > 'Can't find a UDMA66 capable device' > it is > 'Disabling the UDMA66 bios'. > > I've done the usual append for ide3, in lilo.conf but w/o benefit. > > Kernel is currently 2.2.16, > The mobo is an Asus A7V133 and the CPU is an 1.1 Athlon > South bridge is a via 686b which runs fine at UDMA100 on a > pair of Maxtors on IDE-0. > > I'll be upgrading this machine to 2.4.n-whatever in about 3 wks but... > ...I'd like to get the 2 devices operational on this or > some other 2.2.x, before that, if I can. > > I can't find the chip's datasheet. CMD only gives it to direct customers. > I do have the datasheet for the CMD-646U, a prior UDMA supporting chip. > > I take this to be a bug in the on-card Bios. > > I am hoping to circumvent the bios. I assume it will involve some > measure of IDE initialization which I don't mind coding if > it does not exist yet. > > > So has anyone encountered this chip yet and > are there any existing solutions or suggestions. > > > Thanx much > > > The CMD-648 chip's vital statistics follow... > > root@scsoftware50:~# lspci -vvxxxs 00:0c.0 > 00:0c.0 RAID bus controller: CMD Technology Inc PCI0648 (rev 01) > Subsystem: CMD Technology Inc PCI0648 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- > Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 32 (500ns min, 1000ns max) > Interrupt: pin A routed to IRQ 11 > Region 0: I/O ports at 9400 > Region 1: I/O ports at 9000 > Region 2: I/O ports at 8800 > Region 3: I/O ports at 8400 > Region 4: I/O ports at 8000 > Capabilities: [60] Power Management version 1 > Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA > PME(D0-,D1-,D2-,D3hot-,D3cold-) > Status: D0 PME-Enable- DSel=0 DScale=3 PME- > 00: 95 10 48 06 07 00 90 02 01 00 04 01 00 20 00 00 > 10: 01 94 00 00 01 90 00 00 01 88 00 00 01 84 00 00 > 20: 01 80 00 00 00 00 00 00 00 00 00 00 95 10 48 06 > 30: 00 00 00 00 60 00 00 00 00 00 00 00 0b 01 02 04 > 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 > 50: 40 ec 00 c0 00 c0 00 dc 32 40 00 00 00 00 00 00 > 60: 01 00 21 06 00 60 00 f0 00 00 00 00 00 00 00 00 > 70: 00 08 00 f0 94 0a 00 00 00 82 00 f0 c8 01 48 2a > 80: 00 00 00 00 00 00 00 00 00 00 00 00 95 10 48 06 > 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > > - > John Heil > South Coast Software > Custom systems software for UNIX and IBM MVS mainframes > 1-714-774-6952 > [EMAIL PROTECTED] > http://www.sc-software.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/ > Andre Hedrick Linux ATA Development ASL Kernel Development - ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035Web: www.aslab.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: scsi_scan problem.
Ishikawa wrote:
>
> Hi,
>
> I have an "old" Nakamichi CD changer.
> ("old" might be important consideration here. )
>
> Should I test the patch submitted and report what I found ?
> (Or maybe I don't have to bother at this stage at all
> and simply wait for the 2.5 development and debugging cycle?)
It would still be helpful because this problem has to be fixed before 2.5.
The only question is whether to fix it with a simple patch such as I just
submitted, or a more complex patch that uses REPORT LUNs. Part of that answer
is how my simple patch works on your device.
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
-
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] 9 potential copy_*_user bugs in 2.4.1
On Fri, Mar 16, 2001 at 10:06:48AM +, David Woodhouse wrote: > Nice work - thanks. One request though, to you and anyone else doing such > cleanups - please could you list the affected files separately near the > beginning of your mail, so that people can tell at a glance whether there's > anything in there that might be their fault. Also, it'd be nice if the filenames were in alphabetic order. Both points make it much easier to examine the list of affected files. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.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/
IDE UDMA on a CMD-648 Chip
I've acquired a UDMA66 capable IDE card with a CMD-648 chip, which is supposed to provide me with ide2 and ide3. ide2 is empty and ide3 has a writeable cdrom and an IDE zip drive on it. At boot up, the card's bios scan recognizes the cdrom and zip as master and slave on its secondary ide i/f, which is correct. However, it indicates that since it... 'Can't find a UDMA66 capable device' it is 'Disabling the UDMA66 bios'. I've done the usual append for ide3, in lilo.conf but w/o benefit. Kernel is currently 2.2.16, The mobo is an Asus A7V133 and the CPU is an 1.1 Athlon South bridge is a via 686b which runs fine at UDMA100 on a pair of Maxtors on IDE-0. I'll be upgrading this machine to 2.4.n-whatever in about 3 wks but... ...I'd like to get the 2 devices operational on this or some other 2.2.x, before that, if I can. I can't find the chip's datasheet. CMD only gives it to direct customers. I do have the datasheet for the CMD-646U, a prior UDMA supporting chip. I take this to be a bug in the on-card Bios. I am hoping to circumvent the bios. I assume it will involve some measure of IDE initialization which I don't mind coding if it does not exist yet. So has anyone encountered this chip yet and are there any existing solutions or suggestions. Thanx much The CMD-648 chip's vital statistics follow... root@scsoftware50:~# lspci -vvxxxs 00:0c.0 00:0c.0 RAID bus controller: CMD Technology Inc PCI0648 (rev 01) Subsystem: CMD Technology Inc PCI0648 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- http://www.sc-software.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: [PATCH] fix a bug in ioctl(CDROMREADAUDIO) in cdrom.c in 2.2
Pierre Etchemaite wrote: > > Le 14-Mar-2001, Jani Jaakkola écrivait : > > > > Using ioctl(CDROMREADAUDIO) with nframes argument being larger than 8 and > > not divisible by 8 causes kernel to read and return more audio data than > > was requested. This is bad since it clobbers up processes memory > > (I noticed this when my patched cdparanoia segfaulted). > > Same thing for 2.4.2. > > Is my allocation loop "over engineering", or just plain bad thing to do ? > I've been running this (or close: my version tries 8 frames, then jumps immediately to 1, without trying 4 and 2 in between if the kmalloc fails) since it was changed. Without such a patch, my CDDA read speed drops to 25% the original rate. You also have the fix that started the thread! Jens (cdrom maintainer) said he was working on a more elegant solution, but to me, such a simple fix as yours should go in the kernel in the meantime. Jens? -- David Mansfield (718) 963-2020 [EMAIL PROTECTED] Ultramaster Group, LLC www.ultramaster.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: VIA686A chipset crash under 2.4.2-ac20
Andre Hedrick wrote: > Okay not to worry, I now have a my hands on a VIA 686B and will look at > the changes that happened to the VIA686A > > Have you run 2.2.18 plus my patches off kernel.org? > No, I didn't run it. Whould I? -- ** Sincerely yours Kirill Kozmin E-mail:[EMAIL PROTECTED] Homepage:www.ludd.luth.se/~kozkir-8/ ** - 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: How to mount /proc/sys/fs/binfmt_misc ?
On Fri, 16 Mar 2001, David Weinehall wrote:
> On Fri, Mar 16, 2001 at 01:07:17PM -0500, Alexander Viro wrote:
> >
> >
> > On Fri, 16 Mar 2001, Alexander Viro wrote:
> >
> > [snip]
> >
> > > Sure. With all its holes and illetarate C.
> > ^
> > e
> > Apparently, rule about typos in spelling flame are not
> > limited to natural languages...
>
> Oh... Was it a typo? I had a good laugh, because I thought it was
> intended. Especially considering that you left one of the typos
> (I was always taught that it's spelled illiterate...)
Original - typo, the rest (including "rule...are") - not ;-)
Seriously, binfmt_misc.c was written in rather, erm, interesting C.
Read it and you'll see. Just one (but rather impressive) example:
if ((count == 1) && !(buffer[0] & ~('0' | '1'))) {
It was meant to be
if (count == 1 && (buffer[0] == '0' || buffer[0] == '1')) {
and anyone who can't find the difference really should learn C. And
that's not the only bogosity of such level. Besides, the thing is
trivially oopsable - write() to any file in binfmt_misc with buffer
pointing to unmapped kernel address and you are screwed,
-
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[2]: VIA686A chipset crash under 2.4.2-ac20
Okay not to worry, I now have a my hands on a VIA 686B and will look at the changes that happened to the VIA686A Have you run 2.2.18 plus my patches off kernel.org? On Fri, 16 Mar 2001, kozkir-8 wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: MD5 > > It wouldn't be a problem if after these messages fsck wouldn't have > found errors in FS. > > > AH> I am so tired of this report, I am about to hide these in a /dev/null > AH> It is a nothing message. And if the via-core is correct it will auto down > AH> grade the trnasfer rate and you will not feel any effect. Only a > AH> marginally slow disk service. > > > > - -- > Best regards, > Kirill Kozmin > > -BEGIN PGP SIGNATURE- > Version: 2.6 > > iQCVAwUAOrJaHj5SQymVx3NvAQE1NQP6A3Pm9X3EPpOERs6xoTnpc0UpBb5F+l01 > sfzZmqodu4FGvGriFTUAbZNNtrPcE4os9dcnxjHtlfyW4PZ+YyWUjtIekx1ZdbLI > I21hwuA2dA+lyLM5jaAS3aC5mPzfauVMRIbozegtPnaQViWUShSM8x1XWHtsQFBy > iam5xbL8gXo= > =Qxq1 > -END PGP SIGNATURE- > > Andre Hedrick Linux ATA Development ASL Kernel Development - ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035Web: www.aslab.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: How to mount /proc/sys/fs/binfmt_misc ?
On Fri, Mar 16, 2001 at 01:07:17PM -0500, Alexander Viro wrote: > > > On Fri, 16 Mar 2001, Alexander Viro wrote: > > [snip] > > > Sure. With all its holes and illetarate C. > ^ > e > Apparently, rule about typos in spelling flame are not > limited to natural languages... Oh... Was it a typo? I had a good laugh, because I thought it was intended. Especially considering that you left one of the typos (I was always taught that it's spelled illiterate...) /David Weinehall _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re[2]: VIA686A chipset crash under 2.4.2-ac20
-BEGIN PGP SIGNED MESSAGE- Hash: MD5 It wouldn't be a problem if after these messages fsck wouldn't have found errors in FS. AH> I am so tired of this report, I am about to hide these in a /dev/null AH> It is a nothing message. And if the via-core is correct it will auto down AH> grade the trnasfer rate and you will not feel any effect. Only a AH> marginally slow disk service. - -- Best regards, Kirill Kozmin -BEGIN PGP SIGNATURE- Version: 2.6 iQCVAwUAOrJaHj5SQymVx3NvAQE1NQP6A3Pm9X3EPpOERs6xoTnpc0UpBb5F+l01 sfzZmqodu4FGvGriFTUAbZNNtrPcE4os9dcnxjHtlfyW4PZ+YyWUjtIekx1ZdbLI I21hwuA2dA+lyLM5jaAS3aC5mPzfauVMRIbozegtPnaQViWUShSM8x1XWHtsQFBy iam5xbL8gXo= =Qxq1 -END PGP SIGNATURE- - 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] big stack variables
[EMAIL PROTECTED] said: > Erm... That piece is UML-only. Correct, thanks for noticing that. I was a bit over-enthusiastic with my cutting and pasting. Ignore that bit. 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: How to mount /proc/sys/fs/binfmt_misc ?
On Fri, 16 Mar 2001, Richard Guenther wrote: > On Fri, 16 Mar 2001, Alexander Viro wrote: > > On Fri, 16 Mar 2001 [EMAIL PROTECTED] wrote: > > > > > The release notes specify this: > > > > > > mount -t binfmt_misc none /proc/sys/fs/binfmt_misc > > > > > > but this doesn't work because > > > > > > mount: mount point /proc/sys/fs/binfmt_misc does not exist > > > > Grr... OK, I've been an overoptimistic idiot and missed that ugliness. > > > > Solutions: > > a) mount it on some real place. And write there to register > > entries instead of the bogus /proc/sys/fs/binfmt_misc > > b) add a couple of proc_mkdir() into fs/proc/root.c > c) stick with the previous binfmt_misc in 2.4 and leave the >filesystem with 2.5 Sure. With all its holes and illetarate C. - 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: fork and pthreads
On Fri, Mar 16, 2001 at 06:52:26PM +0100, Richard Guenther wrote: > Well, using pthreads and forking in them seems to trigger libc > bugs (read: SIGSEGvs) here under certain conditions (happens, > after I introduced signal handlers and using pthread_sigmask, > I think), so hangs should be definitely possible, too... You must pretty much avoid using signal handlers with pthreads. In stead, you need to carefully setup things such that most signals are blocked in most threads and a single thread (or selected set of threads) does a sigwait for signals of interest. Most good pthreads books talk about this issue, as does the DCE documentation. - 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: VIA686A chipset crash under 2.4.2-ac20
On Thu, 15 Mar 2001, kozkir-8 wrote:
>
> Kernel 2.4.2 with ac20 patch seems doesn't like my motherboard
> I have FIC SD11 with VIA686A chipset. I compiled it with support of
> VIA82Cxxx and DMA support by default. First it seemed like work but
> after a while I started to get errors like these:
>
> kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
I am so tired of this report, I am about to hide these in a /dev/null
It is a nothing message. And if the via-core is correct it will auto down
grade the trnasfer rate and you will not feel any effect. Only a
marginally slow disk service.
> Before I compiled kernel 2.4.2 without ac patches and got the same errors.
>
> HDD Fujitsu MPE3136AT.
>
> Here is a part of config file for kernel (only set variables)
>
> #
> # ATA/IDE/MFM/RLL support
> #
> CONFIG_IDE=y
>
> #
> # IDE, ATA and ATAPI Block devices
> #
> CONFIG_BLK_DEV_IDE=y
> CONFIG_BLK_DEV_IDEDISK=y
> CONFIG_IDEDISK_MULTI_MODE=y
> CONFIG_BLK_DEV_IDECD=y
>
> #
> # IDE chipset support/bugfixes
> #
> 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_BLK_DEV_VIA82CXXX=y
> CONFIG_IDEDMA_AUTO=y
> CONFIG_BLK_DEV_IDE_MODES=y
>
>
> -
> 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/
>
Andre Hedrick
Linux ATA Development
ASL Kernel Development
-
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035Web: www.aslab.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: fork and pthreads
I am not using any signals. All the signals are blocked with SIG_IGN Nitin Sane [EMAIL PROTECTED] *(508)382-7319 -Original Message- From: Craig Ruff [mailto:[EMAIL PROTECTED]] Sent: Friday, March 16, 2001 1:03 PM To: Richard Guenther Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: fork and pthreads On Fri, Mar 16, 2001 at 06:52:26PM +0100, Richard Guenther wrote: > Well, using pthreads and forking in them seems to trigger libc > bugs (read: SIGSEGvs) here under certain conditions (happens, > after I introduced signal handlers and using pthread_sigmask, > I think), so hangs should be definitely possible, too... You must pretty much avoid using signal handlers with pthreads. In stead, you need to carefully setup things such that most signals are blocked in most threads and a single thread (or selected set of threads) does a sigwait for signals of interest. Most good pthreads books talk about this issue, as does the DCE documentation. - 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: How to mount /proc/sys/fs/binfmt_misc ?
On Fri, 16 Mar 2001, Alexander Viro wrote: [snip] > Sure. With all its holes and illetarate C. ^ e Apparently, rule about typos in spelling flame are not limited to natural languages... - 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: fork and pthreads
Hi! Well, using pthreads and forking in them seems to trigger libc bugs (read: SIGSEGvs) here under certain conditions (happens, after I introduced signal handlers and using pthread_sigmask, I think), so hangs should be definitely possible, too... Richard. On Fri, 16 Mar 2001 [EMAIL PROTECTED] wrote: > I am having a strange problem. > > I have a big daemon program to which I am trying to add multi-threading. > > At the begining, after some sanity check, this program does a double fork to > create a deamon. > > After that it listens for the client on the port. Whenever the client > connects, it creates a new thread using > pthread-create. > > The problem is, the thread (main thread) calling pthread-create hangs > indefinetely in __sigsuspend. The newly created thread however, runs > normally to completion. > > I wrote few test programs trying to simulate this behaviour but all of them > worked as expected. > > Does anyone know, what's going on ?? > > Nitin Sane > [EMAIL PROTECTED] > *(508)382-7319 > > - > 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/ > -- Richard Guenther <[EMAIL PROTECTED]> WWW: http://www.anatom.uni-tuebingen.de/~richi/ The GLAME Project: http://www.glame.de/ - 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: How to mount /proc/sys/fs/binfmt_misc ?
On Fri, 16 Mar 2001, Alexander Viro wrote: > On Fri, 16 Mar 2001 [EMAIL PROTECTED] wrote: > > > The release notes specify this: > > > > mount -t binfmt_misc none /proc/sys/fs/binfmt_misc > > > > but this doesn't work because > > > > mount: mount point /proc/sys/fs/binfmt_misc does not exist > > Grr... OK, I've been an overoptimistic idiot and missed that ugliness. > > Solutions: > a) mount it on some real place. And write there to register > entries instead of the bogus /proc/sys/fs/binfmt_misc > b) add a couple of proc_mkdir() into fs/proc/root.c c) stick with the previous binfmt_misc in 2.4 and leave the filesystem with 2.5 Richard. -- Richard Guenther <[EMAIL PROTECTED]> WWW: http://www.anatom.uni-tuebingen.de/~richi/ The GLAME Project: http://www.glame.de/ - 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/
problems compiling scsi_ioctl on kernels later 2.4.1
i tried to compile linux-2.4.3-pre4 on a redhat and suse machine with different gcc's egcs 1.1.2 ,gcc 2.96 and gcc 2.95 but all get stuck on compiling scsi_ioctl in kernel or as module does anyone have an idea? machine's : -pentium 66 (with bug :=) running suse 7.0 -amd athlon 1000 with promise fasttrak running redhat 7.0 Erik - 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: union mounts WAS: pivot_root & linuxrc problem
On Fri, Mar 16, 2001 at 05:05:41PM +0300, Art Boulatov wrote: > I've seen new options for "mount" like --bind, --over, but didn't really > get how they work or are they implemented at all. "mount --bind" works on vanilla 2.4. The others don't. - 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: devfs vs. devpts
John Jasen wrote: > > On 16 Mar 2001, Ian Soboroff wrote: > > > i don't have devpts mounted under 2.4.2 (debian checks whether you > > have devfs before mounting devpts), so i tried building my kernel with > > Unix 98 pty support but without the devpts filesystem. i get the > > following error at the very end of 'make bzImage': > > snipped from .config: > > # > # Character devices > # > CONFIG_VT=y > CONFIG_VT_CONSOLE=y > CONFIG_SERIAL=y > # CONFIG_SERIAL_CONSOLE is not set > # CONFIG_SERIAL_EXTENDED is not set > # CONFIG_SERIAL_NONSTANDARD is not set > CONFIG_UNIX98_PTYS=y > CONFIG_UNIX98_PTY_COUNT=256 > > # > # File systems > # > CONFIG_DEVFS_FS=y > CONFIG_DEVFS_MOUNT=y > CONFIG_DEVFS_DEBUG=y > ... > # CONFIG_DEVPTS_FS is not set > > from my /etc/devfsd.conf, I have: > REGISTERpts/.* MKOLDCOMPAT > UNREGISTER pts/.* RMOLDCOMPAT > > and for permissions: > REGISTERpts/.* IGNORE > I had the same problem, so i added those devfsd lines to my config files, and everything's peachy now. I'm thinking it's a debian problem, cause everything was fine till I ran a dist-upgrade. I didn't notice it right away, and I did random kernel stuff before I did notice it. Ian, which debian are you running, I'm using sid. Nathan - 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: fork and pthreads
[EMAIL PROTECTED] writes: > I am having a strange problem. > > I have a big daemon program to which I am trying to add multi-threading. > > At the begining, after some sanity check, this program does a double fork to > create a deamon. > > After that it listens for the client on the port. Whenever the client > connects, it creates a new thread using > pthread-create. > > The problem is, the thread (main thread) calling pthread-create hangs > indefinetely in __sigsuspend. The newly created thread however, runs > normally to completion. Just a guess--are you calling setsid() to establish a new session? Omitting this *might* cause signal-delivery problems in pthreads. -Doug - 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: scsi_scan problem.
Hi,
I have an "old" Nakamichi CD changer.
("old" might be important consideration here. )
Should I test the patch submitted and report what I found ?
(Or maybe I don't have to bother at this stage at all
and simply wait for the 2.5 development and debugging cycle?)
-
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] big stack variables
On Fri, 16 Mar 2001, Jeff Dike wrote: > +#endif > +#ifdef CONFIG_STDIO_CONSOLE > + stdio_console_init(); > #endif Erm... That piece is UML-only. ObUML: something fishy happens in UML with multiple exec() in PID 1. Try to say "telinit u" (or just boot with init=/bin/sh and say exec /sbin/init) and you've got a nice panic()... - 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] big stack variables
[EMAIL PROTECTED] said:
> I've got my nose stuck in tty_io.c at present - I'll fix this this
> one.
This is the patch I've been carrying around in the UML pool since this bit me:
diff -Naur -X exclude-files orig/drivers/char/tty_io.c um/drivers/char/tty_io.c
--- orig/drivers/char/tty_io.c Thu Feb 22 11:53:50 2001
+++ um/drivers/char/tty_io.cThu Feb 22 11:54:55 2001
@@ -1991,12 +1991,11 @@
{
#ifdef CONFIG_DEVFS_FS
umode_t mode = S_IFCHR | S_IRUSR | S_IWUSR;
- struct tty_struct tty;
+ kdev_t device = MKDEV (driver->major, minor);
+ int idx = minor - driver->minor_start;
char buf[32];
- tty.driver = *driver;
- tty.device = MKDEV (driver->major, minor);
- switch (tty.device) {
+ switch (device) {
case TTY_DEV:
case PTMX_DEV:
mode |= S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH;
@@ -2017,23 +2016,21 @@
(driver->major < UNIX98_PTY_SLAVE_MAJOR + UNIX98_NR_MAJORS) )
flags |= DEVFS_FL_CURRENT_OWNER;
# endif
- devfs_register (NULL, tty_name (&tty, buf), flags | DEVFS_FL_DEFAULT,
+ sprintf(buf, driver->name, idx + driver->name_base);
+ devfs_register (NULL, buf, flags | DEVFS_FL_DEFAULT,
driver->major, minor, mode, &tty_fops, NULL);
#endif /* CONFIG_DEVFS_FS */
}
-void tty_unregister_devfs (struct tty_driver *driver, unsigned minor)
+void tty_unregister_devfs (struct tty_driver *driver, unsigned int minor)
{
#ifdef CONFIG_DEVFS_FS
void * handle;
- struct tty_struct tty;
+ int idx = minor - driver->minor_start;
char buf[32];
- tty.driver = *driver;
- tty.device = MKDEV(driver->major, minor);
-
- handle = devfs_find_handle (NULL, tty_name (&tty, buf),
- driver->major, minor,
+ sprintf(buf, driver->name, idx + driver->name_base);
+ handle = devfs_find_handle (NULL, buf, driver->major, minor,
DEVFS_SPECIAL_CHR, 0);
devfs_unregister (handle);
#endif /* CONFIG_DEVFS_FS */
@@ -2192,6 +2189,9 @@
#endif
#ifdef CONFIG_HWC
hwc_console_init();
+#endif
+#ifdef CONFIG_STDIO_CONSOLE
+ stdio_console_init();
#endif
#ifdef CONFIG_SERIAL_21285_CONSOLE
rs285_console_init();
-
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/
Cannot delete dir
Excuse me, but can anyone tell me how I might delete a directory on a Redhat 6.1 ext2 file system that has permissions drwS--sr-x? Even as root I cannot unlink the directory. - 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/
fork and pthreads
I am having a strange problem. I have a big daemon program to which I am trying to add multi-threading. At the begining, after some sanity check, this program does a double fork to create a deamon. After that it listens for the client on the port. Whenever the client connects, it creates a new thread using pthread-create. The problem is, the thread (main thread) calling pthread-create hangs indefinetely in __sigsuspend. The newly created thread however, runs normally to completion. I wrote few test programs trying to simulate this behaviour but all of them worked as expected. Does anyone know, what's going on ?? Nitin Sane [EMAIL PROTECTED] *(508)382-7319 - 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: Oops 0000 and 0002 on dual PIII 750 2.4.2 SMP platform
Marcelo Tosatti wrote: > > Can you please try to reproduce it with the following patch against 2.4.2? Marcelo (et al), I'll give it a whirl with the patch. Should I also try setting `nmi_watchdog=0' in lilo.conf, as Andrew Morton suggests? Additionally, I'll upgrade my version of ksymoops. Unfortunately, I won't get a chance to test all of this until Monday; at which time I'll report back to the group. v/r Shane -- Shane Y. Gibson[EMAIL PROTECTED] Network Architect (408) 447-8253 work IT Data Center Operations (408) 447-8298 fax Digital Impact, Inc. (650) 302-0193 cellular (888) 786-4863 pager "Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next. -- unknown - 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: How to mount /proc/sys/fs/binfmt_misc ?
Thanks for the quick response. I took your suggestion (a) and created
/etc/binfmt_misc, and set up a test in my rc.local to mount it and register my
usual entries there if /proc/sys/fs/binfmt_misc doesn't exist. So now it works
with both 2.4.3-pre4 and 2.4.2-ac20.
Wayne
Alexander Viro <[EMAIL PROTECTED]> on 03/16/2001 09:37:49 AM
To: Wayne Brown/Corporate/Altec@Altec
cc: [EMAIL PROTECTED]
Subject: Re: How to mount /proc/sys/fs/binfmt_misc ?
On Fri, 16 Mar 2001 [EMAIL PROTECTED] wrote:
> The release notes specify this:
>
> mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
>
> but this doesn't work because
>
> mount: mount point /proc/sys/fs/binfmt_misc does not exist
Grr... OK, I've been an overoptimistic idiot and missed that ugliness.
Solutions:
a) mount it on some real place. And write there to register
entries instead of the bogus /proc/sys/fs/binfmt_misc
b) add a couple of proc_mkdir() into fs/proc/root.c
That is, add
proc_mkdir("sys/fs", 0):
proc_mkdir("sys/fs/binfmt_misc", 0);
after the line that says
proc_mkdir("sys", 0);
I would strongly recommend (a). In the long run we'll need to go that
way.
-
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: How to mount /proc/sys/fs/binfmt_misc ?
[EMAIL PROTECTED] wrote: > > > which makes sense, I guess, because proc isn't a "real" filesystem. So how do I > get binfmt_misc mounted? mount it somewhere else, say, /dev/binfmt_mount instead of in /proc until the proc entry is fixed. What should creat /proc/sys/fs/binfmt_misc ? -Thomas - 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/
APM and cs4281 sound module
Hello, as I posted here ~2 weeks ago my system locks when going to suspend mode. Now I was able to locate the problem in the sound module. (More information at EOF) When I make a 'rmmod cs4281' suspend and resume works very well. System hangs only when suspending with loaded sound module. Kernel is 2.4.2-ac20 lspci -vv 00:08.0 Multimedia audio controller: Cirrus Logic Crystal CS4281 PCI Audio (rev 01) Subsystem: Citicorp TTI Crystal CS4281 PCI Audio Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- | Product Development Astaro AG | http://www.astaro.de | +49-721-490069-0 | Fax -55 PGP signature
Re: smp or die ??!?!
Em Fri, Mar 16, 2001 at 01:52:01PM +, Delfim Machado escreveu: > hi, > > i'm trying to compile my single cpu without the smp and it gives me a > long compile errors ... > > with the smp enable, i can compile all the kernel without any problems make mrproper ? - Arnaldo - 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: devfs vs. devpts
On 16 Mar 2001, Ian Soboroff wrote: > i don't have devpts mounted under 2.4.2 (debian checks whether you > have devfs before mounting devpts), so i tried building my kernel with > Unix 98 pty support but without the devpts filesystem. i get the > following error at the very end of 'make bzImage': snipped from .config: # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y # CONFIG_SERIAL_CONSOLE is not set # CONFIG_SERIAL_EXTENDED is not set # CONFIG_SERIAL_NONSTANDARD is not set CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 # # File systems # CONFIG_DEVFS_FS=y CONFIG_DEVFS_MOUNT=y CONFIG_DEVFS_DEBUG=y ... # CONFIG_DEVPTS_FS is not set from my /etc/devfsd.conf, I have: REGISTERpts/.* MKOLDCOMPAT UNREGISTER pts/.* RMOLDCOMPAT and for permissions: REGISTERpts/.* IGNORE uname -a: Linux grim 2.4.2-ac18 #3 SMP Mon Mar 12 12:05:18 EST 2001 i686 unknown -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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/
pkt_sched.h
Hello,
I have two questoins regarding the pkt_sched.h file.
--
(1)
The pkt_sched.h file have following lines
#define PSCHED_GETTIMEOFDAY 1
#define PSCHED_JIFFIES 2
#define PSCHED_CPU 3
#define PSCHED_CLOCK_SOURCE PSCHED_JIFFIES
Does it means that the PSCHED_GET_TIME(stamp)
use PSCHED_JIFFIES?
If we change it become as follows, then the PSCHED_GET_TIME(stamp)
use PSCHED_CPU?
#define PSCHED_CLOCK_SOUCE PSCHED_CPU
--
(2)
How can we measure the delay of kernel function using
PSCHED_GET_TIME function?
(I only know how to use do_gettimeofday)
do_gettimeofday(&begin);
...
(kernel do something)
...
do_gettimeofday(&end);
if (end.tv_usec < begin.tv_usec) {
end.tv_usec += 100; end.tv_sec--;
}
end.tv_sedc -= begin.tv_sec;
end.tv_usec -= begin.tv_usec;
result = ((end.tv_sec*100) + end.tv_usec);
Thanks a lot.
Cheers,
Steven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Kernel 2.4.2-ac20
Wondering something about this new installation - kernel 2.4.2-ac20. I am running soundmodem as a module and when I run 'insmod soundmodem' I see this: unix:/etc# insmod soundmodem Using /lib/modules/2.4.2-ac20/kernel/drivers/net/hamradio/soundmodem/soundmodem.o /lib/modules/2.4.2-ac20/kernel/drivers/net/hamradio/soundmodem/soundmodem.o: unresolved symbol hdlcdrv_transmitter_Rc7c3 /lib/modules/2.4.2-ac20/kernel/drivers/net/hamradio/soundmodem/soundmodem.o: unresolved symbol hdlcdrv_register_hdlcdrv_R5cc2770d /lib/modules/2.4.2-ac20/kernel/drivers/net/hamradio/soundmodem/soundmodem.o: unresolved symbol hdlcdrv_arbitrate_R6954b1ce /lib/modules/2.4.2-ac20/kernel/drivers/net/hamradio/soundmodem/soundmodem.o: unresolved symbol hdlcdrv_unregister_hdlcdrv_R2d89fb74 /lib/modules/2.4.2-ac20/kernel/drivers/net/hamradio/soundmodem/soundmodem.o: unresolved symbol hdlcdrv_receiver_Rde0ac756 Anyone have any thoughts on this? Why the unresolved symbols?? --- Earth is a beta site. Ted Gervais <[EMAIL PROTECTED]> 44.135.34.201 linux.ve1drg.ampr.org - 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: NTFS R/W safe with mount 'ro' ?
At 11:43 16/03/01, Peter 'Luna' Runestig wrote: >I just noticed that one of the major distros ships their kernel with >NTFS write support turned on. Using such a kernel, am I still safe if I >mount my NTFS partition 'ro'? Yes. Regards, Anton -- Anton Altaparmakov (replace at with @) Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/ ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/ - 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: How to mount /proc/sys/fs/binfmt_misc ?
On Fri, 16 Mar 2001 [EMAIL PROTECTED] wrote:
> The release notes specify this:
>
> mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
>
> but this doesn't work because
>
> mount: mount point /proc/sys/fs/binfmt_misc does not exist
Grr... OK, I've been an overoptimistic idiot and missed that ugliness.
Solutions:
a) mount it on some real place. And write there to register
entries instead of the bogus /proc/sys/fs/binfmt_misc
b) add a couple of proc_mkdir() into fs/proc/root.c
That is, add
proc_mkdir("sys/fs", 0):
proc_mkdir("sys/fs/binfmt_misc", 0);
after the line that says
proc_mkdir("sys", 0);
I would strongly recommend (a). In the long run we'll need to go that
way.
-
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: Performance is weird (fwd) -> results
Sampsa Ranta wrote: > > After either of your patches, the result was the same, sorry. > Is apm or acpi running? -- Manfred - 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/
How to mount /proc/sys/fs/binfmt_misc ?
OK, I've been struggling with this (off and on) since Tuesday, and I give up. Since going from 2.4.3-pre4 to 2.4.2-ac20 I have been unable to use binfmt_misc. Thanks to a hint from Michael Meissner, I found a mention in the release notes for 2.4.2-ac12 that binfmt_misc should be mounted separately. However, I still have a problem. The release notes specify this: mount -t binfmt_misc none /proc/sys/fs/binfmt_misc but this doesn't work because mount: mount point /proc/sys/fs/binfmt_misc does not exist And if I try to mkdir -p /proc/sys/fs/binfmt_misc with /proc mounted I get mkdir: cannot create directory `/proc/sys/fs/binfmt_misc': No such file or directory which makes sense, I guess, because proc isn't a "real" filesystem. So how do I get binfmt_misc mounted? 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/
