PDA

View Full Version : 10.2.1 network freezes - dual processor aggro again?


lx
Sep 29, 2002, 02:34 PM
This is a bit of a survey, after reading Melanie's post below regarding freezing 'all the time'....

I just got a rather nice deal on a remaining top-of-the-line Quicksilver DP 1GHz (was just about to buy a dual 867 new model, but the dual 1GHz was a better deal). Installing 10.2.1 on it results in repeatable and frequent OS freezes.

On my hacked Cube (1 GHz, GF3, max ram), 10.2.1 works and is solid as a rock. On my original 400 MHz TiBook, it's completely solid, even when shagging it by using it as a Sybase server with a 7 GB database :)

However, this rather nice DP powermac locks up whenever doing *anything* with the network. Mounting SMB, Appletalk, NFS, ftp, whatever. Login to the relevant network services works fine, but subsequent access freezes the process, which in turn freezes the finder, any apps, etc.

The nasty thing is that the processes affected get a 'U' status in ps and even kill -9 from root won't kill the process. This presumably means that the kernel itself has lost control, which suggests the freeze happens in a kext (most likely as the majority of freezes are SMB-related, and the smbfs.kext is running in kernel space)

BUT I do a LOT of smb connections with the other 2 Macs, they have never had any aggro, I've never seen the Cube freeze. The TiBook is a slightly different case since it's all on HFS+, whereas the Cube and DP use UFS (for a sybase app I'm porting, I need the case sensitivity for scripts that previously ran on Sun)

SO - anyone out there who is also having 10.2.1 woes, are they network related, and are you all running dual processors?? I recall a similar OSX situation some time back around 10.1.3 where the dualies were affected whilst everything else worked OK.

And no, no dodgy RAM or loads of iffy third party apps. This is a new box and I'm just getting the OS working. Fresh install, and this seems very Unix to me rather than a Cocoa app issue.

lx
Sep 30, 2002, 10:40 AM
Surely I'm not the only one??

cowerd
Sep 30, 2002, 10:46 AM
Have you checked logs. Open them in Console.app

If I remember correctly, networking issues with DP systems were related to solely to issues with a dial-up connection/modem, not with a WAN/LAN.

melanie
Sep 30, 2002, 11:18 AM
No network issues here. I am logged into a Win 2k network(I love the new networking in 10.2, I can now see all the network drives instead of the one I set up for the macs to transfer files. I also log directly into two other macs for file sharing and have had no issues.)I run terminal services for mac and manage the entire network from my powerbook. Says alot when the network administrator uses a mac instead of a pc....given a choice most of our employees would rather have a mac but our proprietary church database software is windows only and runs extremely slow on virtual pc.
I haven't had a freeze yet today but haven't done much except email and surfing the web. I can live with the intermitten freezes as long as I remember to save often.

Melanie
:rolleyes:

michel
Sep 30, 2002, 05:12 PM
i had kernel panics galore and it seemed to be related to network access *after* waking up from sleep. i've since turned off sleep, and have had nary a kernel panic. this is on a dual 1 ghz with 1.5 gig of ram.

lx
Oct 1, 2002, 08:37 AM
Funny that - no kernel panics here. Just the kernel appearing to lock up - nothing in the logs, and the CPU isn't flat out...

I'll try swapping out the RAM - I upgraded the 512 standard MB to 1.5 GB.

someone_else
Oct 1, 2002, 12:28 PM
Originally posted by lx:
Funny that - no kernel panics here. Just the kernel appearing to lock up - nothing in the logs, and the CPU isn't flat out...

I'll try swapping out the RAM - I upgraded the 512 standard MB to 1.5 GB.

When the kernel itself "locks up", that is a panic. What you are describing sounds like a stuck thread that is waiting on some kind of resource. While annoying, it is not as nasty as a panic.

FWIW, I haven't had any of the problems you describe on my DP. I don't use SMB, but I do use ASIP and lots of other networking stuff. Never a problem on 10.2 or 10.2.1.

lx
Oct 1, 2002, 06:05 PM
I always thought a kernel panic was when the kernel actually trapped an exception and halted processing i.e. core dump / screen full of stack trace etc.

What I need a proper Unix guru to tell me is how the hell the system can get to a state where root can't kill -9 a process. The unix developers I know reckon the scheduler should *always* allow the forced termination of stuck threads.

Apart from that one day of issues, everything has been solid - no coredump kernel panics since 10.0 (pulling USB cables after waking from sleep did the trick)

I'm very happy with OSX - just trying to acclimatise to the differences between it and the other Unix variants I know :)

someone_else
Oct 1, 2002, 07:58 PM
Originally posted by lx:
I always thought a kernel panic was when the kernel actually trapped an exception and halted processing i.e. core dump / screen full of stack trace etc.

What I need a proper Unix guru to tell me is how the hell the system can get to a state where root can't kill -9 a process. The unix developers I know reckon the scheduler should *always* allow the forced termination of stuck threads.

Apart from that one day of issues, everything has been solid - no coredump kernel panics since 10.0 (pulling USB cables after waking from sleep did the trick)

I'm very happy with OSX - just trying to acclimatise to the differences between it and the other Unix variants I know :)

It is possible for a process to become "stuck" on any Unix. Anytime a process must wait on disk I/O, it can become stuck. This usually doesn't happen unless your disk is failing. In OS X, there are more situations than disk access where a thread can become stuck. The most common one would be waiting on a kernel only spinlock or mutex. These types of kernel locks are not interruptible. Semaphore locks can be interrupted, but not mutexes or spinlocks. Most networking (generic term) code in the kernel requires use of these types of locks. So if the network dies and the lock does not have some kind of timeout then the thread will be stuck.

HTH.