Bug 53966

Summary:	updfstab eats 80-99% cpu
Product:	[Retired] Red Hat Linux	Reporter:	Mike McLean <mikem>
Component:	kudzu	Assignee:	Bill Nottingham <notting>
Status:	CLOSED RAWHIDE	QA Contact:	David Lawrence <dkl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.3	CC:	rvokal
Target Milestone:	---
Target Release:	---
Hardware:	ia64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-09-27 01:12:31 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Michael A. McLean 2001-09-24 18:28:31 UTC

* re0924.0-ia64
* ia64 / German / NFS / Full Server / post-install: USB ....

Upon fresh insertion of a USB device (I've seen it with a floppy, zip and
even a mouse) updfstab begins consuming nearly all available cpu time. 
Here is a ps capture showing 99% usage:

  F S   UID   PID  PPID  C PRI  NI ADDR    SZ WCHAN  TTY        TIME CMD
000 R     0  1540  1512 99  76   0    -   290 invoke ?          2:45
/usr/sbin/u

For the floppy and zip drives, mounting causes updfstab to exit.  Umounting
later does not cause another cpu drain.  Even reinsertion of the same
device does not cause the drain.

Comment 1 Bill Nottingham 2001-09-26 21:53:59 UTC

Does this happen on all ia64 server machines, or just one particular one?
I can't reproduce this on a workstation machine.

Comment 2 Bill Nottingham 2001-09-26 21:54:18 UTC

(at least not with a USB keyboard)

Comment 3 Michael A. McLean 2001-09-26 22:18:25 UTC

A USB keyboard has never caused the problem, only drives (and a mouse once or
twice, but that is erratic).  I've seen it on 3 of the itaniums.

Comment 4 Bill Nottingham 2001-09-27 01:12:24 UTC

All server boxes, though, yes?

In any case, could you drop one of the drives off by my desk? I'll try and
reproduce it there (easier to debug...)

Comment 5 Bill Nottingham 2001-09-27 19:08:11 UTC

This *should* be fixed with kernel-2.4.9-0.13.