10:28am ghast /home/jamie %uname -a
FreeBSD ghast 7.0-STABLE FreeBSD 7.0-STABLE #0: Fri May 16 10:04:08 EDT 2008 jamie@ghast:/usr/obj/usr/src/sys/ghast i386

The recent Ubuntu Linux security SNAFU reminded me that I hadn't CVSupped in a while, so I did.

My favorite part of tracking RELENG_7:

10:32am ghast /home/jamie %dmesg | grep wpi
wpi0: < Intel(R) PRO/Wireless 3945ABG> mem 0xecfff000-0xecffffff irq 17 at device 0.0 on pci12
wpi0: Ethernet address: 00:19:d2:7a:c8:4b
wpi0: [ITHREAD]

I missed having WiFi support for a while, since the NDIS framework wouldn't work with the Windows NDIS driver when I was tracking RELENG_6...kernel panics as far as the eye could see when I tried to load the module after compiling it.
10:28am ghast /home/jamie %uname -a
FreeBSD ghast 7.0-STABLE FreeBSD 7.0-STABLE #0: Fri May 16 10:04:08 EDT 2008 jamie@ghast:/usr/obj/usr/src/sys/ghast i386

The recent Ubuntu Linux security SNAFU reminded me that I hadn't CVSupped in a while, so I did.

My favorite part of tracking RELENG_7:

10:32am ghast /home/jamie %dmesg | grep wpi
wpi0: < Intel(R) PRO/Wireless 3945ABG> mem 0xecfff000-0xecffffff irq 17 at device 0.0 on pci12
wpi0: Ethernet address: 00:19:d2:7a:c8:4b
wpi0: [ITHREAD]

I missed having WiFi support for a while, since the NDIS framework wouldn't work with the Windows NDIS driver when I was tracking RELENG_6...kernel panics as far as the eye could see when I tried to load the module after compiling it.
10:28am ghast /home/jamie %uname -a
FreeBSD ghast 7.0-STABLE FreeBSD 7.0-STABLE #0: Fri May 16 10:04:08 EDT 2008 jamie@ghast:/usr/obj/usr/src/sys/ghast i386

The recent Ubuntu Linux security SNAFU reminded me that I hadn't CVSupped in a while, so I did.

My favorite part of tracking RELENG_7:

10:32am ghast /home/jamie %dmesg | grep wpi
wpi0: < Intel(R) PRO/Wireless 3945ABG> mem 0xecfff000-0xecffffff irq 17 at device 0.0 on pci12
wpi0: Ethernet address: 00:19:d2:7a:c8:4b
wpi0: [ITHREAD]

I missed having WiFi support for a while, since the NDIS framework wouldn't work with the Windows NDIS driver when I was tracking RELENG_6...kernel panics as far as the eye could see when I tried to load the module after compiling it.
jsbowden: (Wheelie)
( Feb. 28th, 2008 11:36 am)
11:34am ghast /home/jamie %uname -a
FreeBSD ghast 7.0-STABLE FreeBSD 7.0-STABLE #0: Thu Feb 28 11:03:14 EST 2008 root@ghast:/usr/obj/usr/src/sys/ghast i386
jsbowden: (Wheelie)
( Feb. 28th, 2008 11:36 am)
11:34am ghast /home/jamie %uname -a
FreeBSD ghast 7.0-STABLE FreeBSD 7.0-STABLE #0: Thu Feb 28 11:03:14 EST 2008 root@ghast:/usr/obj/usr/src/sys/ghast i386
jsbowden: (Wheelie)
( Feb. 28th, 2008 11:36 am)
11:34am ghast /home/jamie %uname -a
FreeBSD ghast 7.0-STABLE FreeBSD 7.0-STABLE #0: Thu Feb 28 11:03:14 EST 2008 root@ghast:/usr/obj/usr/src/sys/ghast i386
Just for fun:

9:29am ghast /home/jamie %uname -a
FreeBSD ghast 6.3-STABLE FreeBSD 6.3-STABLE #0: Fri Feb 15 10:51:27 EST 2008 root@ghast:/usr/obj/usr/src/sys/ghast i386

9:30am ghast /home/jamie %cat /etc/cvsupfile
*default host=cvsup11.FreeBSD.org
*default base=/usr
*default prefix=/usr
*default release=cvs
*default tag=RELENG_7
*default delete use-rel-suffix

src-all
*default tag=.
ports-all
doc-all

We'll see if it'll still boot after a CVSup and buildworld. I'm pretty sure this isn't the approved way to move from 6-S to 7-S.
Just for fun:

9:29am ghast /home/jamie %uname -a
FreeBSD ghast 6.3-STABLE FreeBSD 6.3-STABLE #0: Fri Feb 15 10:51:27 EST 2008 root@ghast:/usr/obj/usr/src/sys/ghast i386

9:30am ghast /home/jamie %cat /etc/cvsupfile
*default host=cvsup11.FreeBSD.org
*default base=/usr
*default prefix=/usr
*default release=cvs
*default tag=RELENG_7
*default delete use-rel-suffix

src-all
*default tag=.
ports-all
doc-all

We'll see if it'll still boot after a CVSup and buildworld. I'm pretty sure this isn't the approved way to move from 6-S to 7-S.
Just for fun:

9:29am ghast /home/jamie %uname -a
FreeBSD ghast 6.3-STABLE FreeBSD 6.3-STABLE #0: Fri Feb 15 10:51:27 EST 2008 root@ghast:/usr/obj/usr/src/sys/ghast i386

9:30am ghast /home/jamie %cat /etc/cvsupfile
*default host=cvsup11.FreeBSD.org
*default base=/usr
*default prefix=/usr
*default release=cvs
*default tag=RELENG_7
*default delete use-rel-suffix

src-all
*default tag=.
ports-all
doc-all

We'll see if it'll still boot after a CVSup and buildworld. I'm pretty sure this isn't the approved way to move from 6-S to 7-S.
So, I upgraded my machine at home back in late August (or was it early September? It was sometime around then...), and over all, I'm very happy with my machine.

I did have to pull my 80GB SATA drive out, but I replaced with another Seagate 250GB SATA2 identical to the one I ordered initially, and everything is fine now. Apparently, mixing SATA2 HDDs and SATA1 optical drives is fine, but I got weird timeouts and hangs with haveing a SATA1 and SATA2 HDD hanging off the same controller...which I found odd since each drive is on its own "chain".

The primary drive in the machine is one of the Seagates (I have a 200GB ATA150 drive in there too), and it's currently partitioned with a ~90GB WinXP partition, ~90GB Vista, and ~50GB unused, which I was planning on installing FreeBSD on.

I say was because I can't get either the latest 6.3 or 7.0 RC/Beta (I forget which branch is currently Release Candidate and which is in Beta, but it's irrelevant) to boot. At least, not with the keyboard and mouse plugged in.

The kernel hangs when probing the USB controller the mouse and keyboard are plugged in to. It doesn't matter which one...I can move them and it'll just hang later when it gets to that controller. Now, I can turn USB keyboard and mouse support in the BIOS off and it'll boot, but then I can't select which OS I'd like to boot and I'll only ever see Vista since I set it to the default in bcdedit.

Something I noticed that Windows XP and Vista both do is send a power down signal to all USB devices before probing the controller, and then later reactivating the USB devices and figuring out what they are. This is not new Windows behavior. Unpatched XP from an original release install disk does this. I suspect that if I put Win2k on that 50GB unused space, it'd probably do the same thing.

This has never been a problem before, but I have to wonder if there's some bit of the USB spec. that's been ignored by the FreeBSD core team since it hasn't mattered until now. As much as I'm loathe to do it, I guess I'll see if RatHed will boot and install on that space.

But damn it, I REALLY would prefer to run FreeBSD...I've been running FreeBSD continually since 1.1.
So, I upgraded my machine at home back in late August (or was it early September? It was sometime around then...), and over all, I'm very happy with my machine.

I did have to pull my 80GB SATA drive out, but I replaced with another Seagate 250GB SATA2 identical to the one I ordered initially, and everything is fine now. Apparently, mixing SATA2 HDDs and SATA1 optical drives is fine, but I got weird timeouts and hangs with haveing a SATA1 and SATA2 HDD hanging off the same controller...which I found odd since each drive is on its own "chain".

The primary drive in the machine is one of the Seagates (I have a 200GB ATA150 drive in there too), and it's currently partitioned with a ~90GB WinXP partition, ~90GB Vista, and ~50GB unused, which I was planning on installing FreeBSD on.

I say was because I can't get either the latest 6.3 or 7.0 RC/Beta (I forget which branch is currently Release Candidate and which is in Beta, but it's irrelevant) to boot. At least, not with the keyboard and mouse plugged in.

The kernel hangs when probing the USB controller the mouse and keyboard are plugged in to. It doesn't matter which one...I can move them and it'll just hang later when it gets to that controller. Now, I can turn USB keyboard and mouse support in the BIOS off and it'll boot, but then I can't select which OS I'd like to boot and I'll only ever see Vista since I set it to the default in bcdedit.

Something I noticed that Windows XP and Vista both do is send a power down signal to all USB devices before probing the controller, and then later reactivating the USB devices and figuring out what they are. This is not new Windows behavior. Unpatched XP from an original release install disk does this. I suspect that if I put Win2k on that 50GB unused space, it'd probably do the same thing.

This has never been a problem before, but I have to wonder if there's some bit of the USB spec. that's been ignored by the FreeBSD core team since it hasn't mattered until now. As much as I'm loathe to do it, I guess I'll see if RatHed will boot and install on that space.

But damn it, I REALLY would prefer to run FreeBSD...I've been running FreeBSD continually since 1.1.
So, I upgraded my machine at home back in late August (or was it early September? It was sometime around then...), and over all, I'm very happy with my machine.

I did have to pull my 80GB SATA drive out, but I replaced with another Seagate 250GB SATA2 identical to the one I ordered initially, and everything is fine now. Apparently, mixing SATA2 HDDs and SATA1 optical drives is fine, but I got weird timeouts and hangs with haveing a SATA1 and SATA2 HDD hanging off the same controller...which I found odd since each drive is on its own "chain".

The primary drive in the machine is one of the Seagates (I have a 200GB ATA150 drive in there too), and it's currently partitioned with a ~90GB WinXP partition, ~90GB Vista, and ~50GB unused, which I was planning on installing FreeBSD on.

I say was because I can't get either the latest 6.3 or 7.0 RC/Beta (I forget which branch is currently Release Candidate and which is in Beta, but it's irrelevant) to boot. At least, not with the keyboard and mouse plugged in.

The kernel hangs when probing the USB controller the mouse and keyboard are plugged in to. It doesn't matter which one...I can move them and it'll just hang later when it gets to that controller. Now, I can turn USB keyboard and mouse support in the BIOS off and it'll boot, but then I can't select which OS I'd like to boot and I'll only ever see Vista since I set it to the default in bcdedit.

Something I noticed that Windows XP and Vista both do is send a power down signal to all USB devices before probing the controller, and then later reactivating the USB devices and figuring out what they are. This is not new Windows behavior. Unpatched XP from an original release install disk does this. I suspect that if I put Win2k on that 50GB unused space, it'd probably do the same thing.

This has never been a problem before, but I have to wonder if there's some bit of the USB spec. that's been ignored by the FreeBSD core team since it hasn't mattered until now. As much as I'm loathe to do it, I guess I'll see if RatHed will boot and install on that space.

But damn it, I REALLY would prefer to run FreeBSD...I've been running FreeBSD continually since 1.1.
.

Syndicate

RSS Atom

Most Popular Tags

Powered by Dreamwidth Studios

Style Credit

Expand Cut Tags

No cut tags