[Bug 209110] iSCSI root device name should be dynamic
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=209110
--- Comment #13 from Mark McLoughlin <markmc(a)redhat.com> 2008-10-28 03:56:42 EDT ---
(In reply to comment #12)
> What you are seeing here are 2 different problems:
>
> 1) The device name of iscsi disks is not stable
Nope, that's not what I'm saying. My point is that the target name *is* stable
and mkinitrd should be able to map the target name to a device name and map
that device.
> Solution: use a label or uuid for /
Yep - that's one way of doing it, but "mount by target name" is a valid feature
request too IMHO.
> 2) mkinitrd resolves a label / uuid to a device name and puts this in the
> initrd, given 1) we really should stop doing this.
...
> I believe thus that this bug should be renamed:
> "mkrootdev gets passed /dev/foo as rootdev while root should be found by LABEL
> or UUID"
See bug #209473
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
15 years, 6 months
[Bug 353451] stuck grab
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=353451
Dan Williams <dcbw(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |MODIFIED
--- Comment #9 from Dan Williams <dcbw(a)redhat.com> 2008-10-27 23:19:20 EDT ---
applet svn r986
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
15 years, 6 months
[Bug 313231] Unable to link against libhspell
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=313231
Dan Kenigsberg <danken(a)cs.technion.ac.il> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |CLOSED
Resolution| |RAWHIDE
--- Comment #11 from Dan Kenigsberg <danken(a)cs.technion.ac.il> 2008-10-27 18:54:34 EDT ---
should be available now (
ftp://alviss.et.tudelft.nl/pub/fedora/linux/development/i386/os/Packages/hspell-devel-1.0-11.fc10.i386.rpm
)
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
15 years, 6 months
[Bug 229469] NFS fcntl locks being released locally but not on server
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=229469
--- Comment #26 from Trond Myklebust <trond.myklebust(a)netapp.com> 2008-10-27 18:31:33 EDT ---
On the contrary, I do expect it to make a difference, since the code in
nlmclnt_unlock() will call posix_lock_file_wait() in order to free the
vfs lock before it notifies the server. As soon as it does so, the 5
processes that are contending for that lock will attempt to place a
blocking lock with the server, and will start waiting for the UDP callback.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
15 years, 6 months
[Bug 229469] NFS fcntl locks being released locally but not on server
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=229469
--- Comment #25 from Michael Young <m.a.young(a)durham.ac.uk> 2008-10-27 18:10:41 EDT ---
I was actually seeing this on with several processes contending for a lock on a
single machine, so I don't expect the lack of a UDP listener would make much
difference (I could with earlier kernels reproduce the stuck lock problem with
this setup).
The scenario is to run about 5 processes of the demo program at the same time.
When the first lock is released the processes waiting for the lock don't
necessarily acquire the now-freed lock. So far I have only managed to reproduce
this behaviour on a single processor machine which may or may not be
significant.
I am afraid I still haven't had a close enough look at the code to work out
what is happening.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
15 years, 6 months
[Bug 244866] memory leak in hald-addon-hid-ups (again)
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=244866
John Poelstra <poelstra(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
CC| |poelstra(a)redhat.com
--- Comment #9 from John Poelstra <poelstra(a)redhat.com> 2008-10-27 18:07:28 EDT ---
Any chance this problem has been observed in rawhide?
Note, all Fedora 8 bugs will be closed EOL one month after GA of F10....
naturally you can change the version for this bug as applicable.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
15 years, 6 months
[Bug 244866] memory leak in hald-addon-hid-ups (again)
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=244866
18273645 <robin.laing(a)drdc-rddc.gc.ca> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |robin.laing(a)drdc-rddc.gc.ca
--- Comment #8 from 18273645 <robin.laing(a)drdc-rddc.gc.ca> 2008-10-27 13:34:18 EDT ---
I had this bring down my old F7 machine last week and found that it is
affecting my F8 machine at work. 15.3% of 8 gig ram over almost 24 days.
I am not using apcupsd but I do have an APC UPS plugged into my work (F8)
system.
On my F7 system, I found that it climbed drastically while formatting a 1.5T
drive with two partitions. The percentage of memory used went up and as the
percentage of memory went up, SCSI errors started to show up in dmesg.
I am going to test further and maybe even try to format the drive on my work
machine and see what happens.
>From the F8 machine.
top - 11:29:17 up 23 days, 20:37, 3 users, load average: 2.35, 2.65, 2.53
Tasks: 180 total, 4 running, 176 sleeping, 0 stopped, 0 zombie
Cpu(s): 6.2%us, 1.7%sy, 92.0%ni, 0.0%id, 0.0%wa, 0.2%hi, 0.0%si, 0.0%st
Mem: 8200268k total, 8018200k used, 182068k free, 639644k buffers
Swap: 8385888k total, 120k used, 8385768k free, 3844356k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5041 root 20 0 1265m 1.2g 620 S 0 15.4 4:49.41 hald-addon-hid-
32446 rlaing 20 0 1264m 653m 28m S 13 8.2 1774:26 firefox
Restarting hald works well and dropped the load on the system as well.
I am passing this information onto our IT staff to check our other systems and
see if it shows up across all versions we are running.
Note, I did see this on an Ubuntu thread as well so it is an upstream issue.
As the bug can actually bring a machine down, the severity of the problem
should be raised.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
15 years, 6 months