Re: A true package manager.
by Jeff Pitman
On Saturday 06 November 2004 23:21, seth vidal wrote:
> I'd like to see both of these ready for FC4.
I'd also like to see a dist upgrade that works instead of burning CDs or
going through lengthy howtos on how to upgrade from FC55 to FC56
because kernel 7.5 has some new whizbang module that requires
modification of every config file in the system. Just as an example.
Many comments on FC1 to FC2 were that "anaconda" just does a lot smarter
on upgrades than yum/apt. So, maybe a bit more poking around an online
anaconda update without reboot to floppy or some hacked grub boot image
would be great.
--
-jeff
19 years, 6 months
Re: kernel-sourcecode missing?
by Dan Williams
On Mon, 2004-11-01 at 21:02 +0100, Jan Brond wrote:
> The above mentioned document does a good job. Its nice and easy explained.
> Unfortunatly the way of building the kernel is pretty strange/confusing
> and the installing of the kernel (using rpm) took quite some time to
> finish (around 5min which is way more than copying the files to the
> /boot dir and modify grub.conf). Maybe rpm is doing some dependency
> checking before installing the files(maybe it could be switch off to
> improve install time). If you are tweaking the kernel the turnaround
The %install/%post do a lot of hardlinking of files too, I forget
exactly where, probably in /lib and whatnot.
Dan
19 years, 6 months
Re: kernel-sourcecode missing?
by Jan Brond
Paul Iadonisi wrote:
>On Mon, 2004-11-01 at 00:44, Rodd Clarkson wrote:
>
>[snip]
>
>
>
>>It appears to me that there should be some sort of a comment about this
>>somewhere.
>>
>>
>
> Agreed. I haven't checked, but I'll take your word for it that it's
>not in the current release notes.
>
>
>
>>IT should include the following:
>>
>>* A statement that tells the user most things will compile without
>>needed to install the kernel-sourcecode now. (This is why it was an
>>issue for me, and remained an issue until someone told me I no longer
>>needed it).
>>
>>* A link to, or instructions on how to extract and prepare the source
>>from the .src.rpm file.
>>
>>
>
> See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130754 for
>more info. Hopefully, it will be 'ready enough' for the release of FC3
>to reference in the release notes.
>
>
>
The above mentioned document does a good job. Its nice and easy explained.
Unfortunatly the way of building the kernel is pretty strange/confusing
and the installing of the kernel (using rpm) took quite some time to
finish (around 5min which is way more than copying the files to the
/boot dir and modify grub.conf). Maybe rpm is doing some dependency
checking before installing the files(maybe it could be switch off to
improve install time). If you are tweaking the kernel the turnaround
time for compiling, installing and reboot is much slower than with
standard kernel tar ball. A major setback in my mind.
Another thing I have had quite some problems building a new working
kernel based on the souce code (v. 2.6.9-1.643). Everytime I try to run
it I get Kernel Panic - Not Syncing: VFS: Unable to mount root fs on
unknown-block(0,0) (ext2,ext3 is included). I build a similar kernel
under Redhat 7.3 (same computer but kernel tar ball 2.6.9 from
kernel.org) and there I did not have any problems making the kernel
work. Well if someone have had the same problem and could help me solve
the problem I would be greatfull.
Thanks
JanB
19 years, 6 months
Re: Filesystem "binary compatibility" question
by Matthias Saou
Jerone Young wrote :
> A file systems structures do not change accross architetures. So a PPC
> or X86_64 enviroment reads it the same way an i386 enviroment (if they
> programmed it right,and as far as I know xfs is). Now bootable
> partions accross different aritectures is another story :-)
I have no problems accessing from an x86 the ext3 partitions made from the
x86_64 host that are on the same physical disk as that problematic xfs one.
It's not the first time I try, with this exact same disk... last time I
gave up trying to read it from an x86 host, and when I tried looking into
the problem my x86_64 machine was having... gone, it was booting again, so
I just put the disk back in, and it worked fine.
Now, that x86_64 doesn't boot anymore (same problem), and I tried (again)
to access the disk's data from an x86 test machine, and I can mount the
ext3 partitions fine, I can even get the disk's grub to appear and the
kernels tell me that I need a 64bit system for them to work ;-) But trying
to mount that xfs partition (made on the x86_64 host running FC2) gives me
a segfault every time, which is why I was asking : I'm 100% sure my x86_64
FC2 host could still read that partition if it still booted, whereas no x86
FC2 or FCDev can, as I see it...
I've tried searching for info regarding possible incompatibilities for
filesystems between archs, but can't seem to find anything relevant to my
problem.
> If your signature is correct your running FC3 test 2 (and upgraded the
> hell out of it), do a clean install and try RC2.
That's my laptop, a completely different matter :-)
Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 2.91 (FC3 Test 2) - Linux kernel 2.6.9-1.643.radeon
Load : 0.26 0.29 0.31
19 years, 6 months
Re: fc3t3: selinux: useradd
by Dario Lesca
Il sab, 2004-10-23 alle 06:11, Russell Coker ha scritto:
> What error do you get when running useradd from the command line? I'll check
> out the first-boot panel later.
This morning I have install fc3t3 on a VIA VT82xxxxx .... and the
problems has not happened.
All works perfectly, the first-boot have correct created the user and
the useradd command work proper...
This evening, on the server where I have get the error, I will watch
the anaconda-ks.cfg file if I have done some strange setup.
The error that I get was permission deny on file /etc/passwd, then
permission deny on /etc/group file, and then on the /etc/shadow file.
I have check to move the files ...
mv /etc/passwd /etc/passwd.orig
mv /etc/group /etc/group.orig
mv /etc/shadow /etc/shadow.orig
cp -a /etc/passwd.orig /etc/passwd
cp -a /etc/group.orig /etc/group
cp -a /etc/shadow.orig /etc/shadow
and useradd have add the user ....
After this check I have put the 3 files at the original state
(rm /etc/passwd; mv /etc/passwd.orig /etc/passwd; ecc...), then
modify the /etc/grub.conf and disable selinux (selinux=off) and reboot.
After reboot useradd work proper ....
If I can useful to you ... I am here, if I tomorrow have more
information I send you.
Many thanks to all.
--
Dario Lesca <d.lesca(a)solinos.it>
19 years, 6 months
Re: Paralell startup
by "Nils O. Selåsdal"
Kyrre Ness Sjobak wrote:
> I am hearing much good from the gentoo camp about paralell startup, and
> how it brings down boot times to about 30 secounds. Is this possible to
> do with fedora as well?
Timed my box now, 38 seconds to the gdm login shows from I hit enter
in grub. Not that bad imho.
19 years, 6 months
Re: BerkeleyDB and config files
by Roberto Peon
On Friday 15 October 2004 01:12 am, Michael A. Peters wrote:
<SNIP> (subject: redundancy)
>
> They don't need to be.
> You can get redundance either through automated backups which are
> reverted to if corrupt, flat file backups, etc.
Flat files can be backed up as well.
>
> System would still boot if the database was corrupt - flat files are
> also single points of failure. Can you boot if /etc/fstab is crapped?
Configuration files are single point of failures for the processes that
depend on their existance.
If all configuration is stored in one file, then it is more probable that
filesystem corruption will be able to take out that file (and thus all of your
configuration)
<SNIP> (subject: SE-Linux)
> >
> > What's sure is any scripting language will support open/write/read
> > operations on flat files.
>
> Yes - but you then have to write a utility for each different type of
> config file, and then maintain those utilities. Otherwise - you end up
> with a system that is not friendly for the typical desktop user to
> administrate. With an embedded database, such admin tools are trivial -
> you don't have to learn how program xyz pases its config file etc.
>
> > A plain python - or shell, or Perl, ... - script can do the job on
> > flat
> > files also.
>
> Look at the mess that the RH 5/6 configuration tool was - I forget what
> they called it (linuxconfig??), but it often did not work properly, and
> never worked properly with all things, because all the different flat
> files used different syntax in how the config files were used. Some
> were read by a C program, some were sourced by a shell script, etc.
>
> That made it a nightmare to maintain the administration utility.
> With a database, it is much easier. The value for the setting is
> requested from the database, or inserted into the database. It greatly
> simplifies how configuration information is stored and retrieved.
A database does not necessarily make it easier, but it certainly makes it more
centralized.
A properly organized filesystem based approach, however should also be easy to
use.
> And an embedded database is easily backup up. I back up my rpm database
> daily (cron) - it hasn't failed on me in eons, but back when it did
> fail - it was trivial to go to a backup database.
A directory is easy to backup as well.
> An embedded database for system config files does not need to be
> terribly complex, and redundancy could easily be built into a wrapper
> app that handles the request for info. If there is a database integrity
> problem, it alerts the administrator and uses the last backup.
Flat files don't need an additional wrapper to achieve this.
> Clearly you would not want the database to contain data necessary to
> boot, such as your grub.conf info. But stuff like your yum
> repositories, network interface settings, console.perms data, etc. -
> that really would be better off (imho) in a single database.
>
> I know people are put off by this because of what MS did with the
> registry. But that was MS. Gnome does exactly this - a database for
> gnome application settings, gconf - and it works extremely well, and is
> a hell of a lot nicer than config files.
Properly done XML files are pretty darn legible, and by design are easily
extensible.
Parsers for XML exist in many, if not most, scripting languages.
Since XML is text, it isn't all that hard to write a shell script to
modify a few key variables if necessary.
Databases have less tool coverage.
Also, one advantage that I might typically ascribe to databases,
easy search (assuming, of course, that you have the right tool and you don't
have to know the database syntax, or write a program), is not likely to make
any difference, as 'grep' and 'find' are likely to suffice for any
configuration-setting searches.
Databases have one other advantage over flat files: diskspace usage.
A single file is going to be more efficent than a bunch of flat files.
Summary:
Database-based configuration approches have the following advantage:
1) more complete searching mechanisms (depending on the database)
2) better filesystem/filespace efficiency
Database-based configuration approaches suffer from:
1) increased chance of system failure
2) selinux+configuration database requires programmatic/script based
workarounds
3) less tool (scripting, bash, etc) support
4) VERY coarse-grained locking, so multiple simultaneous users suffer
5) Difficult to fix using vi (or some other text editor) in a
disaster-recovery situation
-Roberto JP
19 years, 6 months
Re: BerkeleyDB and config files
by Michael A. Peters
On 10/14/2004 03:32:46 AM, Iago Rubio wrote:
> On Thu, 2004-10-14 at 06:50, Michael A. Peters wrote:
> > I'd like to suggest a change to the way Fedora Core does some
> things.
> > I'm not talking about "standard" linux config files like /etc/
> passwd
> or /
> > etc/group or /etc/fstab (though the latter would be nice) - I'm
> talking
> > about Fedora (and RH I suppose since Fedora has become a RH test
> bed)
> > specific configuration files, such as /etc/security/console.perms
> and /
> > etc/sysconfig/network-scripts/ifcfg-[iface] type stuff.
> >
> > Rather than store them in flat files, which have different
> > configuration parameters depending upon the file etc., use (maybe
> > optionally) BerkeleyDB.
>
> Just to point that I don't like central configuration databases, and
> I
> don't think it's the way to go.
>
> They're single failure points for the whole system.
They don't need to be.
You can get redundance either through automated backups which are
reverted to if corrupt, flat file backups, etc.
System would still boot if the database was corrupt - flat files are
also single points of failure. Can you boot if /etc/fstab is crapped?
>
> In fact with current selinux improvements, you will not be able to
> have
> a central database for all the system, but some smaller databases
> with
> different security contexts, to manage MAC on different roles.
>
> With this scenario, I don't see any improvements with this changes.
The database can only be updated with utility xyz per selinux policy.
utility xyz can then have its own policy with respect to what/where/how
it is called.
SELinux problem is not one that isn't easily solved.
>
> Flat files are pretty nice to manage/label.
>
> > bdb is already needed for the rpm database, so a Fedora system will
>
> > have bdb installed.
> >
> > Both Python and Perl (as well as many other languages) already have
>
> > good bdb interfaces, and both Python and Perl also have gtk+
> bindings
> > too.
>
> What's sure is any scripting language will support open/write/read
> operations on flat files.
Yes - but you then have to write a utility for each different type of
config file, and then maintain those utilities. Otherwise - you end up
with a system that is not friendly for the typical desktop user to
administrate. With an embedded database, such admin tools are trivial -
you don't have to learn how program xyz pases its config file etc.
>
> A plain python - or shell, or Perl, ... - script can do the job on
> flat
> files also.
Look at the mess that the RH 5/6 configuration tool was - I forget what
they called it (linuxconfig??), but it often did not work properly, and
never worked properly with all things, because all the different flat
files used different syntax in how the config files were used. Some
were read by a C program, some were sourced by a shell script, etc.
That made it a nightmare to maintain the administration utility.
With a database, it is much easier. The value for the setting is
requested from the database, or inserted into the database. It greatly
simplifies how configuration information is stored and retrieved.
And an embedded database is easily backup up. I back up my rpm database
daily (cron) - it hasn't failed on me in eons, but back when it did
fail - it was trivial to go to a backup database.
An embedded database for system config files does not need to be
terribly complex, and redundancy could easily be built into a wrapper
app that handles the request for info. If there is a database integrity
problem, it alerts the administrator and uses the last backup.
Clearly you would not want the database to contain data necessary to
boot, such as your grub.conf info. But stuff like your yum
repositories, network interface settings, console.perms data, etc. -
that really would be better off (imho) in a single database.
I know people are put off by this because of what MS did with the
registry. But that was MS. Gnome does exactly this - a database for
gnome application settings, gconf - and it works extremely well, and is
a hell of a lot nicer than config files.
19 years, 6 months
Re: ACPI w/ Radeon Mobility 9600 (was: Re: APM/ACPI on ThinkPads [ SOLVED ])
by Kyrre Ness Sjobak
There is a program called "radeontool" which at least turns of the
backligth of the LCD. I have it in my "open/close lid" ACPI scripts.
IRDA i have never had working. It migth be the physical port, but i
really don't care. Unless i can sync my t610 with evo on my main pc.
(why do i think *go get a cheap usb bluetooth dongle and stick it in*?)
And for sleep 3 i think i need to disable my usb modules?!? How do i
then reload them when comming out of sleep?
ons, 13.10.2004 kl. 19.21 skrev Matthias Saou:
> Satish Balay wrote :
>
> > On Tue, 12 Oct 2004, Philip Balister wrote:
> >
> > > I built the kernel (from the 521 rpm) adding the radeonfb-4g patch
> > > from: http://www.loria.fr/~thome/d600/ and changing the config so
> > > radeonfb was bult in (not a module). I added the patch to the specfile
> > > and used rpmbuild -bp to configure the source (also edited the i686
> > > config file)
> >
> > I tried the 607 kernel on both the 600E & T40 - and both APM & ACPI
> > issues are solved now.
> >
> > With my brief testing - APM works as before. With ACPI the biggest
> > issues was me being a 'clueless user'. The key-binding for
> > 'Recover-from-suspend' from 'power switch' to 'Fn'-key - and I assumed
> > ACPI breakage.
> >
> > However ACPI-sleep still consumes lot more power than APM sleep - this
> > would be an upsteam issue.
> >
> > I gess the radeonfb-4g patch isn't required for T40 with ATI-9000
>
> It is required for my 9600 Mobility :
> - Resuming with the default 607 kernel gives a nasty "melting display"
> effect, although blindly rebooting with "Crtl+Alt+F1" then Ctrl+Alt+Del"
> works.
> - Adding the radeonfb module to the initrd (and video=radeonfb to my
> kernel's grub line) gets me the neat fb using full resolution, but same
> problem when resuming.
> - Rebuilding the kernel rpm with that patch applied and the same settings
> as above gets resume working, with this, though :
>
> Stopping tasks:
> ==========================================================================
> ==============|
> usbhid 2-1:1.0: resume is unsafe!
> radeonfb: suspending to state: 3...
> agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
> agpgart: Putting AGP V2 device at 0000:00:00.0 into 0x mode
> agpgart: Putting AGP V2 device at 0000:01:00.0 into 0x mode
> Back to C!
> zapping low mappings.
> Debug: sleeping function called from invalid context at mm/slab.c:2063
> in_atomic():0[expected: 0], irqs_disabled():1
> [<0211d869>] __might_sleep+0x7d/0x88
> [<0214b7ea>] __kmalloc+0x42/0x7d
> [<02205585>] acpi_os_allocate+0xa/0xb
> [<022192db>] acpi_ut_allocate+0x2e/0x52
> [<02219272>] acpi_ut_initialize_buffer+0x41/0x7c
> [<022160c0>] acpi_rs_create_byte_stream+0x23/0x3b
> [<022174ea>] acpi_rs_set_srs_method_data+0x1b/0x9d
> [<0211be1d>] recalc_task_prio+0x128/0x133
> [<0221ed10>] acpi_pci_link_set+0xfe/0x176
> [<0221f094>] irqrouter_resume+0x1c/0x24
> [<0225453a>] sysdev_resume+0x3e/0xa5
> [<022574b0>] device_power_up+0x5/0xa
> [<0213d3b6>] suspend_enter+0x25/0x2d
> [<0213d424>] enter_state+0x3f/0x5e
> [<0221b8ab>] acpi_suspend+0x3b/0x48
> [<0221c310>] acpi_system_write_sleep+0x5c/0x6d
> [<021653ae>] vfs_write+0xb6/0xe2
> [<02165478>] sys_write+0x3c/0x62
> PCI: Setting latency timer of device 0000:00:1d.0 to 64
> PCI: Setting latency timer of device 0000:00:1d.0 to 64
> PCI: Setting latency timer of device 0000:00:1d.1 to 64
> PCI: Setting latency timer of device 0000:00:1d.1 to 64
> PCI: Setting latency timer of device 0000:00:1d.2 to 64
> PCI: Setting latency timer of device 0000:00:1d.2 to 64
> ACPI: PCI interrupt 0000:00:1d.7[D] -> GSI 11 (level, low) -> IRQ 11
> PCI: Setting latency timer of device 0000:00:1d.7 to 64
> ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 11 (level, low) -> IRQ 11
> ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 7 (level, low) -> IRQ 7
> PCI: Setting latency timer of device 0000:00:1f.5 to 64
> ACPI: PCI interrupt 0000:00:1f.6[B] -> GSI 7 (level, low) -> IRQ 7
> PCI: Setting latency timer of device 0000:00:1f.6 to 64
> zapping low mappings.
> radeonfb: resumed !
> PCI: Enabling device 0000:02:01.1 (0000 -> 0002)
> ACPI: PCI interrupt 0000:02:01.1[A] -> GSI 11 (level, low) -> IRQ 11
> Restarting tasks...<6>usb 2-1: USB disconnect, address 3
> done
> usb 2-1: new low speed USB device using address 4
> input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on
> usb-0000:00:1d.0-1
> ip_tables: (C) 2000-2002 Netfilter core team
> Disabled Privacy Extensions on device 0237d4c0(lo)
> ip_tables: (C) 2000-2002 Netfilter core team
> b44: eth0: Link is up at 100 Mbps, full duplex.
> b44: eth0: Flow control is on for TX and on for RX.
>
> I'm not sure how nasty that "sleeping function called from invalid context"
> error is... everything seems fine after a resume, minus the IrDA it seems,
> I'll need to unload more modules and stop the irda service from my suspend
> script it seems.
>
> Matthias
>
> --
> Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
> Fedora Core release 2.91 (FC3 Test 2) - Linux kernel 2.6.8-1.607.radeon
> Load : 3.25 1.94 0.77
19 years, 6 months
ACPI w/ Radeon Mobility 9600 (was: Re: APM/ACPI on ThinkPads [ SOLVED ])
by Matthias Saou
Satish Balay wrote :
> On Tue, 12 Oct 2004, Philip Balister wrote:
>
> > I built the kernel (from the 521 rpm) adding the radeonfb-4g patch
> > from: http://www.loria.fr/~thome/d600/ and changing the config so
> > radeonfb was bult in (not a module). I added the patch to the specfile
> > and used rpmbuild -bp to configure the source (also edited the i686
> > config file)
>
> I tried the 607 kernel on both the 600E & T40 - and both APM & ACPI
> issues are solved now.
>
> With my brief testing - APM works as before. With ACPI the biggest
> issues was me being a 'clueless user'. The key-binding for
> 'Recover-from-suspend' from 'power switch' to 'Fn'-key - and I assumed
> ACPI breakage.
>
> However ACPI-sleep still consumes lot more power than APM sleep - this
> would be an upsteam issue.
>
> I gess the radeonfb-4g patch isn't required for T40 with ATI-9000
It is required for my 9600 Mobility :
- Resuming with the default 607 kernel gives a nasty "melting display"
effect, although blindly rebooting with "Crtl+Alt+F1" then Ctrl+Alt+Del"
works.
- Adding the radeonfb module to the initrd (and video=radeonfb to my
kernel's grub line) gets me the neat fb using full resolution, but same
problem when resuming.
- Rebuilding the kernel rpm with that patch applied and the same settings
as above gets resume working, with this, though :
Stopping tasks:
==========================================================================
==============|
usbhid 2-1:1.0: resume is unsafe!
radeonfb: suspending to state: 3...
agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V2 device at 0000:00:00.0 into 0x mode
agpgart: Putting AGP V2 device at 0000:01:00.0 into 0x mode
Back to C!
zapping low mappings.
Debug: sleeping function called from invalid context at mm/slab.c:2063
in_atomic():0[expected: 0], irqs_disabled():1
[<0211d869>] __might_sleep+0x7d/0x88
[<0214b7ea>] __kmalloc+0x42/0x7d
[<02205585>] acpi_os_allocate+0xa/0xb
[<022192db>] acpi_ut_allocate+0x2e/0x52
[<02219272>] acpi_ut_initialize_buffer+0x41/0x7c
[<022160c0>] acpi_rs_create_byte_stream+0x23/0x3b
[<022174ea>] acpi_rs_set_srs_method_data+0x1b/0x9d
[<0211be1d>] recalc_task_prio+0x128/0x133
[<0221ed10>] acpi_pci_link_set+0xfe/0x176
[<0221f094>] irqrouter_resume+0x1c/0x24
[<0225453a>] sysdev_resume+0x3e/0xa5
[<022574b0>] device_power_up+0x5/0xa
[<0213d3b6>] suspend_enter+0x25/0x2d
[<0213d424>] enter_state+0x3f/0x5e
[<0221b8ab>] acpi_suspend+0x3b/0x48
[<0221c310>] acpi_system_write_sleep+0x5c/0x6d
[<021653ae>] vfs_write+0xb6/0xe2
[<02165478>] sys_write+0x3c/0x62
PCI: Setting latency timer of device 0000:00:1d.0 to 64
PCI: Setting latency timer of device 0000:00:1d.0 to 64
PCI: Setting latency timer of device 0000:00:1d.1 to 64
PCI: Setting latency timer of device 0000:00:1d.1 to 64
PCI: Setting latency timer of device 0000:00:1d.2 to 64
PCI: Setting latency timer of device 0000:00:1d.2 to 64
ACPI: PCI interrupt 0000:00:1d.7[D] -> GSI 11 (level, low) -> IRQ 11
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 11 (level, low) -> IRQ 11
ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 7 (level, low) -> IRQ 7
PCI: Setting latency timer of device 0000:00:1f.5 to 64
ACPI: PCI interrupt 0000:00:1f.6[B] -> GSI 7 (level, low) -> IRQ 7
PCI: Setting latency timer of device 0000:00:1f.6 to 64
zapping low mappings.
radeonfb: resumed !
PCI: Enabling device 0000:02:01.1 (0000 -> 0002)
ACPI: PCI interrupt 0000:02:01.1[A] -> GSI 11 (level, low) -> IRQ 11
Restarting tasks...<6>usb 2-1: USB disconnect, address 3
done
usb 2-1: new low speed USB device using address 4
input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on
usb-0000:00:1d.0-1
ip_tables: (C) 2000-2002 Netfilter core team
Disabled Privacy Extensions on device 0237d4c0(lo)
ip_tables: (C) 2000-2002 Netfilter core team
b44: eth0: Link is up at 100 Mbps, full duplex.
b44: eth0: Flow control is on for TX and on for RX.
I'm not sure how nasty that "sleeping function called from invalid context"
error is... everything seems fine after a resume, minus the IrDA it seems,
I'll need to unload more modules and stop the irda service from my suspend
script it seems.
Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 2.91 (FC3 Test 2) - Linux kernel 2.6.8-1.607.radeon
Load : 3.25 1.94 0.77
19 years, 6 months
